Bash IF Abfrage, Befehl, Subshell ?

[ren22]

Hallo,

Code: Alles auswählen

#!/bin/bash

testvariable=foo
if [ $(echo "$testvariable" | grep "foo" ) ] ; then
		echo "foooo"
fi

if [ echo "$testvariable" | grep "foo" ] ; then
		echo "foooo"
fi

warum muss man die Abfrage mit "grep" in eine Subshell packen und kann den Code nicht so ausführen wie in der 2ten IF Abfrage des Codebeispiels ohne
das es eine Fehlermeldung gibt:
line 8: [: missing `]'
grep: ]: No such file or directory?

möchte ich man test ? Oder wo kann man dies bzgl. nachlesen ?

Danke

[heisenberg]

Subshell ist nicht nötig und gar ganz übel.

Code: Alles auswählen

testvariable=foo
if [ "$testvariable" == "foo" ] ; then
      echo "foooo"
fi

Wo nachlesen?

-> man bash; Suchen nach "CONDITIONAL EXPRESSIONS"

(Habe gerade nur englische Manpages hier).

[ren22]

guten Abend Heisenberg,

Code: Alles auswählen

testvariable="foo bar"
for i in $testvariable; do
	if [ $(echo "$i" | grep "bar") ]; then
		echo "wir matchen \"bar\" in der subshell"
	fi
	
	if [ echo "$i" | grep "bar" ]; then
		echo "wir matchen \"bar\""
	fi
done

Ausgabe:
line 18: [: missing `]'
grep: ]: No such file or directory
wir matchen "bar" in der subshell
grep: ]: No such file or directory
./f_find_dependencies: line 18: [: missing `]'

Stelle ich die Frage nochmal anders, ich bräuchte ein Befehl der prüft, ob der string enthalten ist in der "testvariable", soweit ist weiß geht das doch nur in einer subshell !?
Achso, und die "testvariable" hat in der Regel unterschiedliche strings(char, Zeichen), aber ich möchte nur bar "matchen" .

[heisenberg]

Ja. Mit RegEx geht auch das:

Code: Alles auswählen

if [[ $var =~ o ]] ; then echo oooo ; fi

Wie gesagt: man bash

[Meillo]

warum muss man die Abfrage mit "grep" in eine Subshell packen

Was du eigentlich willst ist:

Code: Alles auswählen

if echo "$testvariable" | grep -q "foo" ; then
	echo "foooo"
fi

Du brauchst naemlich kein test(1). Test(1) ist auch nichts anderes als ein Befehl, der ausgefuehrt wird und dessen Exitcode bestimmt, ob das if greift. In dem Fall ist dein Befehl aber:

Code: Alles auswählen

echo "$testvariable" | grep -q "foo"

Die Funktion von test(1) ist hier nicht noetig.

Man muss sich bewusst machen, dass die eckigen Klammern nichts als Syntactic Sugar sind, keinesfalls aber if-Syntax. Man kann also sehr wohl if ohne test(1) verwenden!

und kann den Code nicht so ausführen wie in der 2ten IF Abfrage des Codebeispiels ohne
das es eine Fehlermeldung gibt:
line 8: [: missing `]'
grep: ]: No such file or directory?

Das liegt daran, dass die eckigen Klammern eben keine Shell-Syntax sind sondern ein Befehlsname und dessen abschliessendes Argument.

Hier eine Erlaeuterung im Detail:

Code: Alles auswählen

if [ echo "$testvariable" | grep "foo" ] ; then

- Das if testet ob der folgende Befehl (genauer: die folgende Pipeline) also alles bis zum Strichpunkt einen Exitcode von 0 hat, dann wird der Block ausgefuehrt.

- Die Pipeline besteht aus zwei Befehlen:
1) Dem `['-Befehl mit zwei Argumenten (``echo'' und ``"$testvariable"'')
2) Dem `grep'-Befehl mit zwei Argumenten (``"foo"'' und ``]'')

- Der `['-Befehl, der ein Synonym fuer den `test'-Befehl ist, erfordert, dass sein letztes Argument ``]'' ist, falls man ihn als `[' aufruft. (Siehe Manpage.)
Das ist der Grund weshalb du die erste Meldung bekommst.

- Die zweite Meldung kommt von grep(1), das das Argument ``]'' als Dateinamen interpraetiert.



Nicht so verbreitet und in der Syntax auch etwas sperriger, aber eigentlich shellartiger (weil hier keine separaten Befehle noetig sind, wie mit if) ist die Verwendung von case:

Code: Alles auswählen

case "$testvariable" in
*foo*)
	echo "foooo"
	;;
esac

[tobo]

Dich interessiert ja nur der Rückgabewert Demzufolge kannst du sowas machen:

Code: Alles auswählen

if echo "$i" | grep -q "bar"; then
//bzw.
if grep -q "bar" <<< "$i"; then

Ansonsten;

Code: Alles auswählen

//entweder
[[ $i == $2 ]]
//oder
[ $i = $2 ]

[heisenberg]

Noch ein paar Anmerkungen:

a) Als Vergleichsoperator besser = als == verwenden da letzteres eher neu und nicht so verbreitet ist
b) Das gleiche gilt für RegEx
c) Hier grep zu verwenden halte ich für Ressourcenverschwendung
d) Als Alternative zu RegEx gibt es noch die Bash-String-Patterns:

Code: Alles auswählen

if [[ $var = *o* ]] ; then echo oooo ; fi

...und mit Kompatibilität meine ich Bash-Versionen älter als 10 Jahre oder andere Shells(z. B. ksh.) auf anderen Nicht-Linux-Systemem.

[Meillo]

Ansonsten;

Code: Alles auswählen

//entweder
[[ $i == $2 ]]
//oder
[ $i = $2 ]

Ja, aber bitte auch hier gequotet! (Weil: teste i="a b"!)

[Meillo]

a) Als Vergleichsoperator besser = als == verwenden da letzteres eher neu und nicht so verbreitet ist

AFAIR muss bei `[' ein einfaches = zum Vergleich verwendet werden (mindestens aus Kompatibilitaetsgruenden), waehrend man bei `[[' ein == nehmen kann, wie tobo richtig geschrieben hat. Ich vermute, dass alle Shells, die `[[' unterstuetzen darin auch == unterstuetzen.

c) Als Alternative zu RegEx gibt es noch die Bash-String-Patterns:

Code: Alles auswählen

if [[ $var = *o* ]] ; then echo oooo ; fi

Und das geht? Greift hier kein Globbing auf Filenames? Ich kann's noch nicht recht glauben ...

[heisenberg]

Ansonsten;

Code: Alles auswählen

//entweder
[[ $i == $2 ]]
//oder
[ $i = $2 ]

Ja, aber bitte auch hier gequotet! (Weil: teste i="a b"!)

Bei der doppelten eckigen Klammer braucht es kein Quoting, da kein word-splitting und keine Pathname-Expansion stattfindet(siehe man bash). Würde die aber aus Gründen besserer Lesbarkeit trotzdem verwenden.

[Meillo]

Ansonsten;

Code: Alles auswählen

//entweder
[[ $i == $2 ]]
//oder
[ $i = $2 ]

Ja, aber bitte auch hier gequotet! (Weil: teste i="a b"!)

Bei der doppelten eckigen Klammer braucht es kein Quoting, da kein word-splitting und keine Pathname-Expansion stattfindet(siehe man bash). Würde die aber aus Gründen besserer Lesbarkeit trotzdem verwenden.

Ausserdem wissen die wenigsten ueber solche Feinheiten Bescheid und dann schreiben sie die `['-Variante auch ohne Quotes. Unzureichendes Quoting ist eines der groessten Robustheitsprobleme beim Shellscripten.

[newdeb]

AFAIR muss bei `[' ein einfaches = zum Vergleich verwendet werden (mindestens aus Kompatibilitaetsgruenden), waehrend man bei `[[' ein == nehmen kann, wie tobo richtig geschrieben hat. Ich vermute, dass alle Shells, die `[[' unterstuetzen darin auch == unterstuetzen.

Die ksh wünscht sich das sogar

Code: Alles auswählen

$ ksh -nc '[[ x = y ]]'  
ksh: warning: line 1: '=' obsolete, use '=='

[Meillo]

AFAIR muss bei `[' ein einfaches = zum Vergleich verwendet werden (mindestens aus Kompatibilitaetsgruenden), waehrend man bei `[[' ein == nehmen kann, wie tobo richtig geschrieben hat. Ich vermute, dass alle Shells, die `[[' unterstuetzen darin auch == unterstuetzen.

Die ksh wünscht sich das sogar

Code: Alles auswählen

$ ksh -nc '[[ x = y ]]'  
ksh: warning: line 1: '=' obsolete, use '=='

Danke.

Die mksh meckert hier nicht und fuehrt diesen Fall (mit `[[' und `=') sogar in der Manpage als Beispiel an, aber sie unterstuetzt sowohl einfache als auch doppelte Gleichheitszeichen fuer Vergleiche, sowohl bei `[[' als auch beim Builtin `['.


Jetzt hab ich doch noch in POSIX nachgeschaut: Eine POSIX-kompatible Shell muss kein `[[' unterstuetzen. `[[' wird lediglich als bei manchen Shells reserviertes Wort erwaehnt.
http://pubs.opengroup.org/onlinepubs/96 ... shell.html

POSIX test(1) kennt auch kein `==' (was hier auch nicht infrage gestellt worden ist), es wird noch nicht mal erwaehnt. Man findet dort aber einen Hinweis auf `[[', naemlich gleich zu Beginn des Rationale-Abschnitts:

The KornShell-derived conditional command (double bracket [[]]) was removed from the shell command language description in an early proposal. Objections were raised that the real problem is misuse of the test command ([), and putting it into the shell is the wrong way to fix the problem. Instead, proper documentation and a new shell reserved word (!) are sufficient.

http://pubs.opengroup.org/onlinepubs/96 ... /test.html

[ren22]

vielen herzlichen Dank an alle, wieder eine Menge gelernt
@Meilo
dieses

Code: Alles auswählen

` '

,(die beiden Zeichen!), ist eine andere Art in "Hochkomma" zu stellen, dass finde ich sehr verwirrend! ??

Man muss sich bewusst machen, dass die eckigen Klammern nichts als Syntactic Sugar sind, keinesfalls aber if-Syntax.

Und die eckigen Klammern sind nichts anderes, als der Befehl "test", wenn ich es richtig verstanden habe?
Würde in Kombination mit "if" natürlich (wobei hier das Wort "Natürlich" hier sehr schwer wiegt in diesem Satz,) eine Logik bilden ,,, klar .. logisch geil

[Meillo]

@Meilo
dieses

Code: Alles auswählen

` '

,(die beiden Zeichen!), ist eine andere Art in "Hochkomma" zu stellen, dass finde ich sehr verwirrend! ??

Das verstehe ich. Man sieht diese Verwendung von Anfuehrungszeichen nicht mehr oft ... bloss noch in Latex (manchmal), in troff und m4. Frueher hatten die Fonts auch noch eine symmetrische Darstellung der beiden Zeichen ... aber die Zeiten aendern sich halt. Ich hoffe, du warst nicht zu sehr verwirrt.

Man muss sich bewusst machen, dass die eckigen Klammern nichts als Syntactic Sugar sind, keinesfalls aber if-Syntax.

Und die eckigen Klammern sind nichts anderes, als der Befehl "test", wenn ich es richtig verstanden habe?

Genau, siehe:

Code: Alles auswählen

/usr/bin/[

(Der einzige Unterschied ist, dass bei einem Aufruf als `[' das letzte Argument ein ``]'' sein muss, waehrend das beim Aufruf als `test' nicht der Fall sein darf.)

[weedy]

Hallo,

Code: Alles auswählen

#!/bin/bash

testvariable=foo
if [ $(echo "$testvariable" | grep "foo" ) ] ; then
		echo "foooo"
fi

if [ echo "$testvariable" | grep "foo" ] ; then
		echo "foooo"
fi

warum muss man die Abfrage mit "grep" in eine Subshell packen und kann den Code nicht so ausführen wie in der 2ten IF Abfrage des Codebeispiels ohne
das es eine Fehlermeldung gibt:
line 8: [: missing `]'
grep: ]: No such file or directory?

möchte ich man test ? Oder wo kann man dies bzgl. nachlesen ?

Danke

Lass die Klammern einfach weg.

Code: Alles auswählen

+$ testvariable=foo
+$ if echo "$testvariable" | grep "foo"; then
+>  echo fooo
+> fi
foo
fooo

Gruß

[breakthewall]

Ausserdem wissen die wenigsten ueber solche Feinheiten Bescheid und dann schreiben sie die `['-Variante auch ohne Quotes. Unzureichendes Quoting ist eines der groessten Robustheitsprobleme beim Shellscripten.

Aus dieser Sicht ist das natürlich einleuchtend, dass man das gewissermaßen einheitlich hält. Ebenso die Nutzung von Backticks kann sehr verwirrend sein, wenn $(...) doch viel sinnvoller erscheint und dasselbe tut, ohne teils eigensinnige Nebeneffekte. Bezüglich des unzureichenden Quotings, könnte die Aussage kaum wahrer sein. So oft selbst erlebt in der Vergangenheit. Insbesondere im Umgang mit exotischen Datei -und Ordnernamen wird das problematisch, oder wenn einfach nur Leerzeichen darin enthalten sind.

[heisenberg]

Code: Alles auswählen

+$ testvariable=foo
+$ if echo "$testvariable" | grep -q "foo"; then
+>  echo fooo
+> fi
fooo

Rein um zu verstehen, was abläuft: Ja.

Zum verwenden: Nein, da unnötig ineffezient.

Die oben vorgestellten Methoden sind besser.

Das Konstrukt echo irgendwas | Kommando mag man in der Shell so benutzen und da ist auch nix dabei. Doch im Skript würde ich da immer auf den zusätzlichen unnötigen Befehl verzichten und statt dessen die Variante Kommando <<<"irgendwas" bevorzugen.

Google useless use of cat / useless use of echo

[Meillo]

Das Konstrukt echo irgendwas | Kommando mag man in der Shell so benutzen und da ist auch nix dabei. Doch im Skript würde ich da immer auf den zusätzlichen unnötigen Befehl verzichten und statt dessen die Variante Kommando <<<"irgendwas" bevorzugen.

... aber mit /bin/bash im Shebang.

Oder du verwendest case, dann geht's auch portabel und ohne zusaetzliche Prozesse.

Google useless use of cat / useless use of echo

Da gibt es solche und andere Meinungen: http://marmaro.de/docs/chaosseminar/on-performance/

[ren22]

Subshell ist nicht nötig und gar ganz übel.

Warum ist subshell ganz übel, verstehe ich nicht so ganz wie Du das meinst mit "ganz übel"

[heisenberg]

Eine Subshell oder ein externer Befehl - z. B. grep bedeutet, dass die laufende Prozessumgebung(Speicher) einmal komplett im RAM kopiert wird und anschliessend der gewünschte Befehl, z. B. grep oder eben wieder die Shell in die Kopie des Speichersegment geschrieben und dann ausgeführt. Im Vergleich dazu laufen Funktionen der Shell in der aktuellen Umgebung mit dem aktuell geladenen Programm(=Shell)

Eine Pipe aus 8 externen Befehlen erzeugt also 8 zusätzliche Prozesse.

Das kann bei großen Shellprogrammen, die ineffizient Programmiert wurden, tausende solcher Prozesserzeugungen verursachen und das Programm um Welten langsamer und Ressourcenhungriger werden lassen.

NACHTRAG

Deutlich hat man das beim letzten Scriptcontest gesehen: Die Anfangsvariante hat ca. 7 Sekunden gebraucht. Nachdem die Prozesserzeugungen wegoptimiert waren noch Null-komma-irgendwas.

[Meillo]

Eine Subshell oder ein externer Befehl - z. B. grep bedeutet, dass die laufende Prozessumgebung(Speicher) einmal komplett im RAM kopiert wird [...]

In Zeiten vor COW war das mal so. Heute wird nur kopiert was noetig ist.

Natuerlich ist das mehr Aufwand, aber das ist halt die eine Seite eines Kompromisses auf dessen anderer Seite die Einfachheit (und damit Verstaendlichkeit und Fehlerminimierung) der Software und dessen groessere Flexibilitaet durch orthogonale Kombinierbarkeit stehen. Eine klare Antwort, wie man diesen Kompromiss entscheiden soll, gibt es IMO nicht -- mal ist der eine Aspekt wichtiger, mal der andere.

[heisenberg]

Natürlich ist das mehr Aufwand, aber das ist halt die eine Seite eines Kompromisses auf dessen anderer Seite die Einfachheit (und damit Verstaendlichkeit und Fehlerminimierung) der Software und dessen groessere Flexibilitaet durch orthogonale Kombinierbarkeit stehen. Eine klare Antwort, wie man diesen Kompromiss entscheiden soll, gibt es IMO nicht -- mal ist der eine Aspekt wichtiger, mal der andere.

Ohne Anspruch auf die einzig richtige Lösung haben zu meinen, kann ich keinen Verständnisvorteil von einer Pipechain im Vergleich zu einer Folge von Einzelbefehlen/-funktionen sehen. In der persönlichen Anwendungserfahrung ist das Pipe-Prinzip eher so: Ich papp' solang' was hintendran, bis es geht. Das läuft darauf hinaus, dass der Prozess eher unnötig komplex wird, also das Gegenteil von einem Verständnisvorteil.

Aber vielleicht machen andere das ja anders.

Ansonsten zeigen die vorliegenden Trivialbeispiele IMHO auch eher eine größere Komplexität und schlechtere Lesbarkeit als die logischen Ausdrücke.

Aber das mag jeder für sich selbst entscheiden.

Wartbarkeit und Effizienz sind IMHO zwei elementare Schwerpunkte. Ich sehe nicht, dass sich die beiden zwangsläufig ausschließen. Eher das Gegenteil: Effiziente Programme können sehr simpel sein und deswegen einfach zu verstehen. Im Gegensatz zur einfachen Lesbarkeit erfordern einfache und effiziente Lösungen mitunter ein erhebliches Maß an Hirnschmalz.

Das alles seine Vor- und Nachteile hat und seinen Einsatzzweck ist klar.

Ich denke auch dass es eine Frage der Gewohnheit ist. Bei mir weicht die Gewohnheit des hintereinanderpappens zunehmend den gelernten und geübten von mir erwähnten Methoden. Zumindest sobald dieser Code es Wert ist in eine Datei geschrieben zu werden.