Mailinglist Archive: opensuse-de (4684 mails)

[Thomas Michalka <Thomas.Michalka@xxxxxx>]

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