Hallo,
Ich habe mir ein kleines Script geschrieben, das meine Lazarus-Anwendung
komprimieren soll. (Linux/Debian sh Script)
1
#!/bin/sh
2
echo
3
echo Komprimiere Programm... ${PWD}
4
cd out
5
strip --strip-all FWUpdate
6
upx -9-q FWUpdate
7
exit 0
Aber nix geht und google half mir leider auch nicht weiter. Darum die
Frage:
Wie kriege ich das Script fehlerfrei zum Laufen?
Die Fehler bei Ausführung:
Problem ist wohl der cd Befehl -- Rest hättest nicht posten brauchen.
Probier mal das Bash- bzw. Shell-Script nur mit dem cd Befehl.
Und dann probier mal einen absoluten Pfad:
cd out
pwd
pwd gibt dir den absoluten Pfad, beispielsweise "/home/stefan/out".
Im Script verwende dann die Ausgabe von pwd, also etwa
cd "/home/stefan/out"
Autor: Matthias (Gast)
>ich wuerds mal mit "cd /out" probieren
Das macht doch nur Sinn, wenn out ein Verzeichnis auf der obersten Stufe
wäre, wie /etc /home /usr usw.
Vielleicht ist es doch ein Problem mit den Berechtigungen?
Bei mir funktioniert cd im Script problemlos, sowohl mit vollständigen
als auch lokalen Pfaden.
Und wenn das Verzeichnis nicht gefunden wird kommt bei mir eine Meldung
wie
stefan@AMD64-X2 ~/Bash $ cd kjhgfg
-bash: cd: kjhgfg: Datei oder Verzeichnis nicht gefunden
Seltsam.
Also nicht einmal das "pwd" funktioniert im Script ??!?!
Hat noch jemand eine Idee, was ich installieren muss. Ich nutze
Sidux/Debian und hab es frisch installiert.
Ich habs getestet unter meinem User Name und mit root, es geht einfach
nicht.
> Wie kriege ich das Script fehlerfrei zum Laufen?
Indem du das Skript im Unix-Format (NL als Zeilenende) statt im
MSDOS-Format (CR/NL als Zeilenende) speicherst.
@Stefan Salewski:
> Und wenn das Verzeichnis nicht gefunden wird kommt bei mir eine> Meldung wie>> stefan@AMD64-X2 ~/Bash $ cd kjhgfg> -bash: cd: kjhgfg: Datei oder Verzeichnis nicht gefunden
Markus verwendet nicht die bash, sondern die dash. Da sehen die
Fehlermeldungen etwas anders aus.
yalu wrote:
> Indem du das Skript im Unix-Format (NL als Zeilenende) statt im> MSDOS-Format (CR/NL als Zeilenende) speicherst.
Wollt ich auch gerade sagen.
Schau mal dein Script im HexEditor an, das Zeichen am Zeilenende muss
0x0A sein, bei DOS/WIN ist das 0x0D, 0x0A (zwei Zeichen).
Das Script funktioniert aber nur mit einem Zeichen.
Na, ja. Um ein richtiges Linux Script zu generieren musste ich mein XP
mit Notepad++ nutzen, der hat einen Konverter auf Unix drin.
Jetzt klappt auch der Script. Vielen Dank für die Hinweise!
sh ist doof. Jede menge super tolle funktionen drin, aber wenn ein CR
kommt, dann bringt der nicht einmal eine Warnmeldung. Ist doch wohl
schrottig und schlampig programmiert.
(Habe Datei mit KWrite bearbeitet.)
> Um ein richtiges Linux Script zu generieren> musste ich mein XP mit Notepad++ nutzen
Du Armer! Richtige Unix-Scripte (Linux-Scripte) kann man normalerweise
auch mit richtigen Unix (Linux) erstellen. Hatte dein Linux Dialekt
keinen Editor, daß du auf Windows ausweichen mußtest?
> Ich bin echt sauer auf diese Linux-Scheisse.
Das hat nix mit Linux zu tun. Das mit den unterschiedlichen
Zeilenschaltungen bei Windows bzw. *NIX, *NUX und co (CR bzw. CR-LF) gab
es schun seit 1970 seit den Urzeiten von UNIX. Da gab es die Micro*ft
Scheisse noch nicht. Hätte sich Billy-Boy an die damaligen Standards
gehalten und nix neues erfunden, dann wäre das problem heute nicht da
(trift auch z.B. auf die Pfadangabe mit / bzw. \ zu)
Warum bist du sauer?
Nur weil du nicht weist wie man mit sh und skripten um geht?
Wenn der Bauer nicht schwimmen kann da liegt es auch grundsätzlich der
Badehose oder ?
> PS: Ich bin echt sauer auf diese Linux-Scheisse. Hängt den> programmierer auf!
In Unix/Linux-Shell-Skripten ist <CR> (also das Zeichen mit dem
ASCII-Code 13) ein ganz normales Zeichen wie 'a' oder 'b'. Steht in
deinem Skript also
1
cd out<CR>
wird nach einem Verzeichnis mit dem Namen out<CR> gesucht und in deinem
Fall natürlich nicht gefunden. Ein Syntaxfehler ist das nicht, da <CR>
(wie auch jedes andere Zeichen außer '/' und <NULL>) in
Datei-/Verzeichnisnamen vorkommen darf. Und dass Steuerzeichen in
Dateinamen vorkommen dürfen, ist die konsequente Umsetzung der (in
meinen Augen sehr löblichen) Unix-Philosophie, funktionelle
Einschränkungen, die nicht technisch bedingt sind, zu vermeiden.
Damit solche Unfälle mit Steuerzeichen nicht passieren, werden alle
außer <TAB> und <NL> von den meisten Unix/Linux-Texteditoren im Klartext
angezeigt (<CR> bspw. als ^M, weil das Zeichen auf der Tastatur mit
Strg-M eingegeben wird).
Wenn man Cross-Development macht, also auf einem System Anwendungen für
ein anderes System entwickelt, muss man sich vorher im Klaren darüber
werden, welche Tools man dazu benötigt. Genauso, wie sich mit dem
Visual-C++-Compiler keine Programme für einen AVR-Controller entwickeln
lassen, kann man mit mit den meisten Windows-Texteditoren keine
Shell-Skripte für Linux schreiben.
Fazit: Der Bug sitz mal wieder, wie so oft, vor dem Computer ;-)
>Oder doch?
Oder.
Du gehörst zu den 70% der Weltbevölkerung, die niemals mit Linux umgehen
können werden. Macht ja nix, wir können schneller expandieren ohne euer
Gejammer und ohne eure unverständlichen Fragen.
Wenn du cool sein willst, benutze cygwin unter Windows, das kann auch
mit kranken Windows-Konventionen umgehen. Aber benutze bitte nie wieder
echtes Linux.
Markus wrote:
> Fazit:> Wenn ich in einem Dateinamen ein <LF> drin stehen habe, dann kann ich> die Datei nicht mit einem sh Script niemals bearbeiten.> Oder doch?
Doch. Dateinamen dürfen alle Zeichen außer / enthalten. Punkt. Also:
1
$ echo "blabla" > "Datei
2
mit
3
Leerzeilen
4
drinne"
5
$ ls
6
blabla???
ls maskiert die Leerzeilen als "?" damit die Ausgabe nicht zerschossen
wird.
Linus wrote:
>>Doch. Dateinamen dürfen alle Zeichen außer / enthalten. Punkt.>> Dürfen sie nicht. Was sie enthalten KÖNNEN, steht auf einem anderen> Blatt.
Was "dürfen" sie denn außer / und evtl. dem Nullbyte bei
nicht-UTF-System noch nicht enthalten?
>Was "dürfen" sie denn außer / und evtl. dem Nullbyte bei>nicht-UTF-System noch nicht enthalten?
RTFM. Du brauchst dich ja nicht dran zu halten. Du begehst auch keine
Straftat, wenn du andere Zeichen benutzt. Aber im Sinne des Standards
darfst du eben nicht alles, was du kannst.
Linus wrote:
>>Was "dürfen" sie denn außer / und evtl. dem Nullbyte bei>>nicht-UTF-System noch nicht enthalten?>> RTFM. Du brauchst dich ja nicht dran zu halten. Du begehst auch keine> Straftat, wenn du andere Zeichen benutzt. Aber im Sinne des Standards> darfst du eben nicht alles, was du kannst.
Ja, habs gelesen (und nicht zum ersten Mal...) trotzdem find ich nix
Verbotenes. Der ganze Name darf nicht "." und auch nicht ".." sein,
klar, aber ansonsten find ich nur Empfehlungen, aber keine Verbote.
>aber ansonsten find ich nur Empfehlungen, aber keine Verbote.
Ja, es wird auch nur empfohlen, nicht den Bootsektor mit beliebigen
Zeichen zu füllen, aber verboten ists nicht. Weißt du, mir geht dein
Ich-habs-ja-nicht-so-gemeint-wie-ich-geschrieben-habe-Gerede auf den
Senkel. Du kannst mit deinen Dateien machen was du willst, aber
verbreite dein Unwissen doch besser nicht in Foren. Ja?
Es geht hier doch wohl nach wie vor um das Script sh.
Wenn ich das Script mit "sh -v" ausführe, dann erwarte ich doch dass mir
gezeigt wird warum der Script nicht funktioniert.
Wenn das Linuxdoof sh mir dann folgende Zeile ausgespuckt hätte:
cd out^M
dann hätte ich nicht 3 Stunden nach dem scheiß Fehler gesucht und auch
nicht dieses Forum belästigt.
Wie schon geschieben, sh ist doof.
Das händling der "Unsichtabren Zeichen" ist ja wohl verbesserungsdürftig
und würen es den Windows Linux Umsteigern einfacher machen.
Nur wenn natürlich die Linux nutzer kein Interesse daran haben künftig
Windows User zu gewinnen, dann seid Ihr selbst schuld. Ich bin
programmierer schon seid vielen Jahren und programmiere prinzipiell
Fehlertollerant gegenüber allem was von aussen kommen kann und bringe
ordentliche Warnungen / Hinweise damit es auch ein DAU kapiert.
Anders ist Linux, wenn man da was falsches benutzt, dann Absturz, wub
wub weg.
Ehrlich, bei so'nen Nörglern die keine Ahnung von garnix haben und wenn
einmal was nicht klappt gleich rumheulen ist es "uns" egal.
Hättest du dich vorher ein bisschen über die Sache informiert, wär dir
der Zeilenumbruch als mögliche Fehlerursache aufgefallen.
Aber du stellst dich lieber hin und erklärst Sachen für doof, die du
nichtmal ansatzweise kennst oder verstehst, die Shell ist recht mächtig,
du kannst damit zB. auch problemlos GUI Programme schreiben.
Linus wrote:
>>aber ansonsten find ich nur Empfehlungen, aber keine Verbote.> Ja, es wird auch nur empfohlen, nicht den Bootsektor mit beliebigen> Zeichen zu füllen, aber verboten ists nicht. Weißt du, mir geht dein> Ich-habs-ja-nicht-so-gemeint-wie-ich-geschrieben-habe-Gerede auf den> Senkel. Du kannst mit deinen Dateien machen was du willst, aber> verbreite dein Unwissen doch besser nicht in Foren. Ja?
Komm mal wieder runter: Ich habe das genau so gemeint, wie ich es
geschrieben habe. Dateinamen dürfen außer Schrägstrich und Nullbyte alle
Zeichen des Zeichensatzes enthalten. Was das jetzt mit Unwissen zu tun
hat, weiß ich nicht, und warum du dich direkt angepisst fühlst, weiß ich
leider auch nicht. Also pöbel hier nicht rum, sondern zeig eine Manpage
auf, oder das "andere Blatt", wo drauf steht, was sie enthalten
können/dürfen, wenn du meinst, es genauer spezifizieren zu
können/müssen. Oder sei einfach still.
Und Markus: Komm du auch mal wieder runter. Ich hab mich auch anfangs
geärgert, wie du gerade. Aber frag dich mal, was Windows machen würde,
wenn die Zeilenenden nach Linux-manier ankämen.
Markus schrieb:
> Wenn ich das Script mit "sh -v" ausführe, dann erwarte ich doch dass> mir gezeigt wird warum der Script nicht funktioniert.
Es wäre zu schön, wenn es einen Interpreter oder Compiler gäbe, der
einem bei einem syntaktisch korrekten Programm ganau sagt, warum es
nicht das tut, was man sich eigentlich vorgestellt hat ;-)
> Wenn das Linuxdoof sh mir dann folgende Zeile ausgespuckt hätte:>> cd out^M
Außer dir hat das so etwas bisher wahrscheinlich kaum jemand benötigt.
Aber du kannst das ja als neues Feature vorschlagen. Hier ist die
Web-Seite der von dir benutzten Shell:
http://gondor.apana.org.au/~herbert/dash/> Das händling der "Unsichtabren Zeichen" ist ja wohl verbesserungsdürftig> und würen es den Windows Linux Umsteigern einfacher machen.
Bei Windows ist es nicht besser, im Gegenteil. Schau die folgende
Batch-Datei an:
1
RMDIR leeresverzeichnis
2
DIR /S /Q wichtigedateien
3
...
Zuerst wird leeresverzeichnis gelöscht. Falls es wider Erwarten nicht
leer sein sollte, erscheint die Meldung "Das Verzeichnis ist nicht leer"
und es wird nicht gelöscht. Dann wird das Verzeichnis wichtigedateien
rekursiv (/S) und mit Ausgabe des Dateibesitzers (/Q) aufgelistet. Also
alles ganz harmlos.
Was würde aber wohl passieren, wenn diese Batch-Datei auf einem
Mac-Editor (mit CR als Zeilenende) geschrieben worden wäre?
Da cmd.exe alle alleinstehenden CRs (und damit alle Zeilenenden)
ignoriert, werden alle Zeilen der Batch-Datei zu einer einzigen
zusammengefasst:
Dieser Befehl löscht leeresverzeichnisdir und wichtigedateien
rekursiv (/S) und ohne Sicherheitsabfrage (/Q). leeresverzeichnisDIR
wird wahrscheinlich nicht gefunden, aber die Daten in wichtigedateien
sind futsch.
Und was wäre, wenn die Batch-Datei folgendermaßen fortgesetzt würde?
1
REM ***********************************************
2
REM * Windows ist in C:\ installiert. *
3
REM * In D:\ E:\ und F:\ liegen die User-daten. *
4
REM ***********************************************
ABER BITTE NICHT AUSPROBIEREN!!!
> Ich bin programmierer schon seid vielen Jahren ...
Das kann ich kaum glauben, sonst hättest du keine 3 Stunden vergeblich
nach dem Fehler gesucht. Oder bist du HTML-Programmierer ;-)
Diese Ausgabezeilen
1
': No such fileate
2
^^^
3
: not foundd
4
^
hätten dir nämlich zeigen müssen, dass da etwas in der Ausgabe
überschrieben wurde. Das passiert typischerweise entweder bei
Pufferüberläufen im Programm oder eben bei der Ausgabe eines CR, wo
keins hingehört.
Thread beobachten
Seitenaufteilung abschalten