Moin, On Fre, 02 Mai 2003 at 17:09 (+0200), Thomas Michalka wrote: [...]
Ich möchte vorab nur bemerken, daß _mein_ Skript ganz ausgezeichnet funktioniert. Deshalb nehme ich Deinen Kommentar mal einfach als
Sonst hätte ich schon danach gefragt ;-) [Zeilenlänge]
Aber bei Skripten habe ich, ehrlich gesagt, nichts gegen eine Zeilenlänge bis 100 Zeichen. In normalem Text habe ich auch 70 - 80 Zeichen *viel* lieber.
Hmm, auch innerhalb eines Scripts kann man (meist) mit 70 - 80 Zeichen gut leben, man kann die Zeilen ja per \ fortsetzen. Aber das ist mehr oder weniger Geschmacksache. [...]
jan@k500:~/tmp> ls -l /bin/gawk /usr/bin/cut -rwxr-xr-x 1 root root 209420 Mär 25 2002 /bin/gawk -rwxr-xr-x 1 root root 18968 Mär 23 2002 /usr/bin/cut
Aber sei mal ehrlich, sollte mich das bei 1 GB Hauptspeicher wirklich jucken?
Ja, das sollte eigentlich _immer_ eine Rolle spielen. Auch 1 GB RAM sind mal alle (Unix ist ein Multi-User-System, man sollte immer davon ausgehen, dass man nicht allein auf dem System arbeitet).
jan@k500:~/tmp> echo "1 2 3" | awk ' { print $'$pos' } ' 2
Lediglich das Konstrukt $'$pos' muss zusammen geschrieben werden.
So ist es! Eigentlich wollte ich mich nur auf das Statement innnerhalb der Klammer beziehen, aber ich habe das nicht korrekt ausgedrückt.
Das obige Konstrukt lebt ja davon, dass dem awk quasi ein { print $2 } *untergeschoben* wird. Man kann dem awk aber auch Shell-Variablen übergeben: jan@k500:~> echo pos1 pos2 pos3 | awk ' { print $pos } ' pos=2 pos2 [...]
Schaut auch recht schön aus. Für mich war es nur alles andere als selbstverständlich, daß read einmal von stdin und von einer Zeichenkette so liest, daß nach jedem Whitespace quasi neu begonnen wird mit dem Lesevorgang.
Genauer gesagt ist es die Variable $IFS, die bestimmt, welche Zeichen als Trenner genutzt werden. Das kann man durch Setzen von IFS steuern. [...]
if [ 0 -eq $(mount | grep -c "\/dev\/hdb$devnum") ] ; then
David würden sich jetzt wieder die Fußnägel aufrollen ;-)
Wen meinst Du? Ich habe von keinem David in diesem Thread gelesen, oder ist das so ein Insider-Witz?
Naja, ein wenig. David Haller schreibt hier sehr oft (im Moment ist er wohl ausser Haus ;-) - unter anderem zu Shell-Themen und bei dem obigen umständlichen Konstrukt hätte er mit Sicherheit rumgemosert.
if ! mount | grep -q /dev/hdb$devnum; then
Du meine Güte, es geht wohl immer noch irgendwie einfacher? Aber ich habe nun mal nicht die Zeit, immer noch etwas päpstlicher als der Papst zu sein ;-)
Man muss sich beim Bash-Scripting einfach immer wieder die Tatsache ins Gedächtnis rufen, dass die if-Abfrage einfach auf 0 / 1 reagiert. Auch der test (die [] sind auch nur ein Aufruf von test) liefert nur ein 0 oder != 0 zurück. Darum kann man beim Prüfen des Erfolgs eines Kommandos den test getrost weglassen, weil er in diesem Fall nur doppelt gemoppelt ist. [...]
und ich würde den Status abfragen! if ! mount /dev/hdb$devnum $MP_DIR/$mpoint; then echo Fehler beim mount exit 1 fi
Ist natürlich viel sauberer. Aber wenn das Gerät schon gemountet ist, ergibt 'echo $?' -> 32. In dem Fall soll das Skript weitermachen. Deshalb ist Deine Lösung hier auch etwas zu einfach. (Keine Angst, damit komme ich klar :-) )
Nein, wir befinden uns im Script hier im Zweig (siehe oben): if ! mount | grep -q /dev/hdb$devnum; then Der Fall *schon gemountet* kann an dieser Stelle also nicht eintreten. Welchen Sinn hätte sonst die if-Afrage?
rsync $RSYNC_OPTS $source/ $MP_DIR/$mpoint/ & PID_RSYNC=$! wait $PID_RSYNC 2> /dev/null ; echo "done (process $PID_RSYNC)."
Auch hier wieder: Was hat es für einen Sinn, das Kommando in den Hintergrund zu schicken, wenn Du doch auf die Beendigung wartest?
Das hier hat den historischen Grund, daß nach dem Start von rsync noch andere Jobs parallel laufen sollten, aber sichergestellt werden mußte, daß der nächste rsync-Job _nach_ dem vorherigen gestartet würde. Die Teile zwischen PID_RSYNC=$! und dem wait-Kommando wurden gelöscht, aber der Rest sollte erhalten bleiben, falls es sich wieder einmal anders ergeben würde.
OK, dann macht es Sinn. Ich halte es dann so, dass ich einen Kommentar an die betreffende Stelle schreibe (nach dem Motto: # hierher kommen alle parallel-Jobs) um selbst nach einem halben Jahr noch durchzusteigen, warum ich so und nicht anders gescriptet habe.
Danke nochmals für die nützlichen Hinweise. Kannst Du mir vielleicht ein Buch über die Bash empfehlen? Ich habe da eher an ein Nachschlagewerk gedacht, als an ein klassisches Lehrbuch, was man von vorne bis hinten durcharbeiten muß. Ich brauche eigentlich auch keine Hinweise über das Programmieren als solches, eher schon weitergehende Tips über effizientes Scripting mit der bash. Und das wichtigste: Einen guten und ausführlichen Index sollte es haben.
Im allgemeinen wird der Kofler (Michael Kofler: Linux - Installation, Konfiguration, Anwendung; Addison-Wesley; ISBN 3-8273-1475-5) als Einsteigerbuch empfohlen, der befasst sich aber nicht nur mit der bash. Stöbere mal bei O'Reilly rum, deren Titel sind eigentlich immer zu empfehlen. Ansonsten sind die im System vorhandenen Scripts eine gute Lektüre. Jan