Jan Trippler schrieb:
Moin,
On Fre, 02 Mai 2003 at 17:09 (+0200), Thomas Michalka wrote: [...]
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).
Ja, ok. Mir ist es auch schon mal passiert, daß ein amoklaufender Prozeß (kein Skript) das System lahmgelegt hat, denn nachdem er fast den ganzen Speicher belegt hat, fing das System an, ohne Ende zu swappen. Interaktion war dann passe.
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
Das ist doch keine Parameterübergabe im eigentlichen Sinn, also kein Argument für awk. Die Zuweisung pos=2 gehört doch zur Bash. *Bevor* awk letztlich aufgerufen wird, wird schon in der Shell 'pos' durch '2' ersetzt, oder sehe ich das falsch?
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.
Ja, das habe ich inzwischen auch nachgelesen. Schon wieder was neues gelernt :-))
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.
Das war mir schon klar. Der Grund für dieses Konstrukt von mir war, daß ich die Option '-q' von grep nicht kannte (siehe meine Antwort an Bernd). Ich habe ja eben nicht den Erfolg von grep getestet, sondern dessen Ausgabe der Anzahl von Fundstellen in der mount-Ausgabe.
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?
Ja klar, die if-Abfrage davor, ob das Gerät gemountet ist hatte ich an dieser Stelle schon wieder vergessen (knirsch :-\ ) Aber Bernd hat's auch nicht gemerkt ;-)
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.
Eine ältere Ausgabe davon habe ich, aber die bleibt trotz der vielen Seiten bei dem meisten Dingen ziemlich an der Oberfläche. Aber das war wohl Absicht. 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.
Das gilt, wie ich finde, für die wenigsten. Die meisten sind IMHO äußerst bescheiden bzw. gar nicht kommentiert. Wenn man dauernd damit befaßt ist, reicht einem (dem Autor) das vielleicht, aber anderen ... Bei vielen Skripten hat man nicht mal den Eindruck, daß die Bash hier eine Programmiersprache bereitstellt. Wenn man zum Beispiel irgendwelche nichtoffensichtlichen Zeichenmanipulationen vornimmt, sollte man wenigstens kommentieren, *was* man da tut, vielleicht auch *warum*. Das *wie* kann man getrost der Recherche des Lesers überlassen, denn die Syntax muß man eh lernen. Allerdings ist einiges schon recht tricky programmiert - um das zu verstehen muß man schon ein Bash-Kenner sein. Auch nicht gerade im Sinne der Transparenz und Wartbarkeit ... Gruß, Tom