wanne hat geschrieben: 
28.02.2020 19:59:33
Die bash hat leider extrem viele ausnahmen, die dafür sorgen dass das Ding meistens das macht was der User will. Das führt zu einer recht komplexen Syntax mit diversen Spezialfällen.
Das klingt etwas negativer als ich es sagen wuerde. In den Randbereichen der Syntax wird's zwar oefters mal interessant, aber mit ein paar wenigen Regeln kommt man normalerweise ziemlich weit.
$() funktioniert so, dass du darin eine normale Kommandozeile reinsetzen kannst -- genau so wie sie ist -- und deren Ausgabe dann an diese Stelle ersetzt wird, in der gleichen Weise, wie wenn die Ausgabe in einer Variable waere.
Dieser Befehl:
kann 1:1 so in eine Kommandosubstitution ($()) gesetzt werden.
Wenn die Ausgabe der Kommandosubstitution dann fuer den umgebenden Befehl als ein Wort aufgefasst werden soll (z.B. wenn Whitespace enthalten ist), dann muss die Kommandosubstitution mit Double-Quotes umgeben werden, weil sie andernfalls nochmal in Worte gesplittet wird.
Als Faustregel sollte man in der Shell alle Variablenexpansionen und alle Kommandosubstitution in Double-Quotes setzen! Nur wenn man das explizit nicht will, muss man sie weglassen. In obigem Beispiel sollte als `$dev' auch gequotet sein, und sei es nur deshalb, weil man fast immer das Verhalten von gequoteten Variablenexpansionen haben will, was im ungequoteten Fall nur zufaellig gleich ist, wenn kein Whitespace enthalten ist.
In dieser Hinsicht ist die Shell tatsaechlich anders als die meisten Programmiersprachen ... aber sie ist auf ihre Weise (zumeist) einheitlich, bloss halt ungewohnt.
$() kann man schachteln. Sie funktionieren dann automatisch richtig.
Quotes kann man nicht schachteln (weil es keinen Unterschied zwischen oeffnendem und schliessendem Quote gibt). (Im Gegensatz zu m4-Macros, im Uebrigen, wo ` und ' verwendet wird.)
Sowas geht also nicht:
Fuer die Shell sind das zwei Woerter:
1) ``echo''
2) ``"Er sagte: "Halt!""''
Beim zweiten Wort wird das Quoting verarbeitet:
Teil 1) ``"Er sagte: "''
Teil 2) ``Halt!''
Teil 3) ``""'' (d.h. ein leerer String)
An `echo' wird dann das Argument ``Er sagte: Halt!'' uebergeben.
Anders saehe es in dem Fall aus:
Hier sind es zwei Woerter:
1) ``"Er sagte: "Sofort''
2) ``Anhalten!""'
Den Unterschied merkt man, wenn man z.B. alle Leerzeichen verdoppelt:
Code: Alles auswählen
$ echo "Er sagte: "Sofort Anhalten!""
Er sagte: Sofort Anhalten!
Innerhalb der Quotes wird der Whitespace bewahrt, zwischen seinen Argumentengibt echo immer genau ein Leerzeichen aus.
Wenn man nun aber eine Kommandosubstitution (oder eine Subshell) verwendet, dann steigt man damit eine Ebene tiefer. Das innerhalb der Klammern hat nichts mehr mit dem ausserhalb der Klammern zu tun. Ausgehend von diesem Befehl:
Code: Alles auswählen
if [ -z "$(iwvdrv "$dev" scan | grep -i "ssid: $ssid")" ] ; then ...
... mal eine Zerlegung nach Ebenen:
Code: Alles auswählen
if ; then ...
[ -z " " ]
$( )
iwvdrv " " scan |
$dev
grep -i " "
ssid: $ssid
(Mir geht es hier nicht um hundertprozentige Korrektheit, sondern um Anschaulichkeit.)
Quotes sind jeweils nur auf ihrere Ebene relevant. Man sieht schoen, dass die Quotes auf Ebene 2 nichts mit denen auf Ebene 4 oder 6 zu tun haben.
Btw:
"$( )" wird wie "$@"als ein geschlossener Ausdruck zu verstehen sein [...]
"$@" ist ein Sonderfall, der anders funktioniert als alles andere Quoting. (Soviel zu meiner Aussage oben.
)
$* verhaelt sich regelkonform: Alle Argumente werden Space-getrennt hintereinander an diese Stelle gesetzt, dann wird nochmal wortgetrennt.
"$*" verhaelt sich regelkonform: Alle Argumente werden Space-getrennt hintereinander als *ein* Wort an diese Stelle gesetzt.
$@ verhaelt sich identisch zu $*.
"$@" ist ein Sonderfall: Alle Argumente werden, jedes fuer sich separat als ein Wort doublegequotet, an diese Stelle gesetzt.
"$@" hat man eingefuehrt, nachdem man gemerkt hat, dass $* nicht funktioniert, wenn die Argumente Spaces enthalten. Dadurch ist $* so gut wie nutzlos geworden.
Die Unix Shell ist schon sehr speziell was das Wortsplitting angeht, verglichen mit normalen Programmiersprachen. Man muss akzeptieren, dass man fuer sie ein anderes Paradigma lernen muss. Alles in der Shell sind Strings und Stringersetzungen. Das ist wie ein Macroprozessor.
Wenn man diese Idee in sehr viel konsistenter Form erleben will, sollte man sich TCL anschauen. Dort findet man die Vollendung der Textersetzung (ohne die Inkonsistenten der Shell). Und TCL schlaegt dann auch den Bogen bis zu LISP, wo alles Listen sind. ... aber das geht jetzt natuerlich alles sehr weit ueber die eigentliche Frage hinaus.
experiementiren eher zufällig diese Lösung gefunden, die auf einmal funktioniert hat:
Jetzt hast du's geschnallt. 
