staging.inyokaproject.org

Da ich gar nicht eine Tabelle als zwingend ansehe kann ich mich gut mit der Idee einer Subseite anfreunden. ☺

Servus ☺

scheint mir eine größere Sache zu sein und habe den Artikel mal in die Baustelle geschoben 😉

Viel Erfolg!

Gruß
kaputtnik

user unknown schrieb:

Früher war bei GNU/Linux-Distributionen /bin/sh meistens ein symbolischer Link auf /bin/bash, weshalb beide Zeilen in der Praxis meistens den gleichen Effekt hatten.

Ich glaube es hat nicht den gleichen Effekt, sondern ein Skript mit #!/bin/sh - Shebang, welches als foo.sh, ./foo.sh oder sh foo.sh aufgerufen wird, wird die Bash dazu veranlassen, im Posixmodus zu agieren. Ob damit alle Erweiterungen hinfällig sind, oder nur konfligierende Interpretationen - müßte man nochmal nachlesen oder ausprobieren.

Hmm, ich tippe eher auf letzteres. Nach Überfliegen der Manpage denke ich, dass sich die Verhaltensänderung hauptsächlich auf Startup-Files bezieht. Und die Praxis sagt:

$ cat foo.sh
foo=(1 2 3)
echo ${foo[1]}

$ bash foo.sh 
2

$ sh foo.sh      # mein /bin/sh ist ein Link auf die Bash
2

$ bash --posix foo.sh
2

$ POSIXLY_CORRECT=1 bash foo.sh
2

$ dash foo.sh
foo.sh: 1: Syntax error: "(" unexpected

Die Beispiele mit den Arrays unten, da sollten Dinge wie „echo ${array[@]}“ dringend gequotet werden. Und ein Wort dazu, warum.

Nein. Es sollte gequotete und ungequotete Beispiele geben, denn viele Arrayinhalte müssen nicht gequotet werden, und dann sollte der User wissen, dass beides möglich ist, und wieso manches gequotet werden soll. Beispiel:

1 2 3 4

jahreszeit=("Frühling" "Sommer" "Herbst" "Winter") for i in {0..3}; do echo ${jahreszeit[i]} ; done hackerzeit=("*.sh" "Eto'o" "$PWD" "$(date)") for i in {0..3}; do echo ${hackerzeit[i]} ; done

Okay, so ein veranschaulichendes Beispiel ist eine gute Idee. Trotzdem finde ich, dass „immer quoten“ eigentlich sauberer ist. Erstens kann sich später einmal der Array-Inhalt ändern und dann müsste man noch im Kopf haben, „oh, ich habe im Rest des Skriptes ja an Quotes gespart“. Zweitens kann es sich im dümmsten Fall um Benutzereingaben handeln, von denen der Skriptschreiber anfangs nur blind annimmt, dass die harmlos sind.

Mein Bauchgefühl sagt mir einfach: „Immer quoten außer in begründeten Ausnahmefällen ist best practice.“

Aber eigentlich wäre das ja eine Sache für den (hypothetischen) Abschnitt zu Quoting im Allgemeinen. Bei den Arrays könnte man dann auf die Besonderheiten bzgl. Arrays eingehen, zum Beispiel:

1. ${foo[*]} = ${foo[@]}: Alle Elemente mit Globbing.

2. "${foo[*]}": Kein Globbing, Elemente getrennt durch erstes Zeichen aus $IFS, Endergebnis ein Wort.

3. "${foo[@]}": Kein Globbing, jedes Element wird ein eigenes Wort.

$ touch a b c

$ foo=('1      2' 3 4 '*')

$ IFS=';'

$ set -x

$ echo ${foo[*]} = ${foo[@]}
+ echo '1      2' 3 4 a b c = '1      2' 3 4 a b c
1      2 3 4 a b c = 1      2 3 4 a b c

$ echo "${foo[*]}"
+ echo '1      2;3;4;*'
1      2;3;4;*

$ echo "${foo[@]}"
+ echo '1      2' 3 4 '*'
1      2 3 4 *

Zum Rest: D’accord. 😉

Hab’ jetzt mal versucht, den Abschnitt zur Shebang ausführlicher zu gestalten, ohne dabei allzu weit auszuschweifen. Und die ulkige „born again shell“ getötet.

Hallo,

IMHO ist die Hinweisbox nach wie vor nicht ok - weil immer noch der "wenn möglich /bin/sh" Hinweis, welcher im Kontext des Artikels aber n.i.o. ist:

IMHO besser:

Die Angabe kann hier nach Wunsch variieren und jede andere Shell beinhalten. Hierbei sollte man aber bedenken, dass man sich dann genauer mit der Syntax dieser auseinandersetzen sollte. Dieser Artikel hingegen basiert auf der Syntax der Bash. Verwendet man eine andere Shell (z.B. Zsh) oder man programmier voll POSIX-konform, so ist die She-Bang entsprechend anzupassen.

Gruß, noisefloor

Sorry, da komme ich gerade nicht mit. In der Box steht nichts mehr von „wenn möglich /bin/sh“, nur der allgemeine Hinweis auf die Besonderheit mit /bin/sh als Link zur Dash bei Ubuntu. 😕 Da könnte man lediglich noch dazuschreiben, dass das bei vielen anderen Distris nicht der Fall ist.

(Euer gängiges Vorgehen ist doch, die Artikelkopie in der Baustelle zu bearbeiten – oder hab ich das jetzt verfriemelt?)

Hallo,

oh, sorry! War in der falschen Revision. Vergesst einfach mit letztes Posting...

Gruß, noisefloor

Hallo,

so jetzt aber: 😀

Ich würde noch den Satz

Ein Bash-Skript darf also niemals /bin/sh als Shebang verwenden – dies funktioniert lediglich in Ausnahmefällen.

steichen, weil es a) so pauschal nicht stimmt und b) die richtige und ausführliche Erklärung im Abschnitt danach kommt.

Sonst IMHO ok.

Gruß, noisefloor

😉

Hmm, doch, ich denke, der Satz stimmt so. Ein Bash-Skript ist ein Shellskript, das Bash-spezifische Funktionen benutzt. /bin/sh garantiert nur für POSIX-Funktionen. Also darf ich nicht erwarten, dass mein Bash-Skript von /bin/sh korrekt ausgeführt wird.

Klar kann das zufälligerweise funktionieren. Aber imo ist es falsch.

Hallo,

hm... ok.

Dann aber vllt. diesen Absatz hinter den mit der Erklärung. Dann kommt erst die Erklärung und dann die "Maßnahme" - vom Ablauf her IMHO besser. ☺

BTW: ist die DASH jetzt eigentlich voll POSIX-konform oder nur fast? So ganz klar kommt das auf den div. Internetseiten dazu nicht raus...

Gruß, noisefloor

noisefloor schrieb:

Dann aber vllt. diesen Absatz hinter den mit der Erklärung. Dann kommt erst die Erklärung und dann die "Maßnahme" - vom Ablauf her IMHO besser. ☺

Jau, done. ☺

BTW: ist die DASH jetzt eigentlich voll POSIX-konform oder nur fast? So ganz klar kommt das auf den div. Internetseiten dazu nicht raus...

Laut Autor ist sie: http://gondor.apana.org.au/~herbert/dash/

Trotzdem kann sie auch wieder mehr als POSIX. Zum Beispiel kennt die Dash „-p“ als Parameter für „read“, was es so in POSIX 2008 nicht gibt.

(Bei der ganzen Sache haben wir übrigens außen vor gelassen, welche Version von POSIX gemeint ist… Da kenne ich mich bei den Unterschieden aber auch nicht so gut aus.)

Vain schrieb:

BTW: ist die DASH jetzt eigentlich voll POSIX-konform oder nur fast? So ganz klar kommt das auf den div. Internetseiten dazu nicht raus...

Laut Autor ist sie: http://gondor.apana.org.au/~herbert/dash/

Trotzdem kann sie auch wieder mehr als POSIX.

POSIX-konform zu sein heißt aber doch, dass man mindestens den POSIX-Standard implementiert, nicht dass man genau diesen - nicht mehr oder weniger kann.

Wieauchimmer bin ich mal wieder zu Experimenten geschritten, habe die Manpage von Bash nach POSIX abgesucht, und probiert 2 Scripte zu machen, die sich nur im Shebang unterscheiden, und die ich jeweils per ./NAME starte:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

#!/bin/bash
# If  the  time  reserved  word  precedes  a  pipeline, the elapsed as well as user and system time consumed by its execution are
#   reported when the pipeline terminates.  The -p option changes the output format to that specified  by  POSIX.   The  TIMEFORMAT
#   variable  may  be  set to a format string that specifies how the timing information should be displayed; see the description of
#   TIMEFORMAT under Shell Variables below.
time ls | sort | wc 

# source filename [arguments]
#    Read and execute commands from filename in the current shell environment and return the exit status of the last  command
#    executed  from  filename.   If filename does not contain a slash, file names in PATH are used to find the directory con‐
#    taining filename.  The file searched for in PATH need not be executable.  When bash is not in posix  mode,  the  current
#    directory is searched if no file is found in PATH.  If the sourcepath option to the shopt builtin command is turned off,
#    the PATH is not searched. 
. fromWhere
echo $fromWhere 

Aufruf mit /bin/bash-Shebang und ./btest.sh:

1
2
3
4
5
6
7

./btest.sh 
    112     114    1484

real	0m0.006s
user	0m0.004s
sys	0m0.004s
forum

Aufruf mit /bin/sh-Shebang und als ./stest.sh, sh ist ein Link auf /bin/dash, ansonsten alles identisch:

1
2
3
4
5

./stest.sh 
0.00user 0.00system 0:00.01elapsed 72%CPU (0avgtext+0avgdata 3696maxresident)k
0inputs+0outputs (0major+295minor)pagefaults 0swaps
    112     114    1484
.: 16: fromWhere: not found

sh ist ein Link auf /bin/bash:

1
2
3
4
5
6
7

./stest.sh 
    112     114    1484

real	0m0.014s
user	0m0.000s
sys	0m0.004s
./stest.sh: Zeile 16: .: fromWhere: Datei nicht gefunden.

Wie man sieht ist die Lage unübersichtlich - auch wenn /bin/sh ein Link auf /bin/bash ist verhält sich das Skript unterschiedlich, je nach dem, ob es so oder so aufgerufen wird, und /bin/sh mit bash im Hintergrund ist auch nicht identisch mit /bin/sh mit dash im Hintergrund.

Vain schrieb:

Okay, so ein veranschaulichendes Beispiel ist eine gute Idee. Trotzdem finde ich, dass „immer quoten“ eigentlich sauberer ist. Erstens kann sich später einmal der Array-Inhalt ändern und dann müsste man noch im Kopf haben, „oh, ich habe im Rest des Skriptes ja an Quotes gespart“. Zweitens kann es sich im dümmsten Fall um Benutzereingaben handeln, von denen der Skriptschreiber anfangs nur blind annimmt, dass die harmlos sind.

Mein Bauchgefühl sagt mir einfach: „Immer quoten außer in begründeten Ausnahmefällen ist best practice.“

Gegen Bauchgefühl und Empfinden kann ich natürlich nicht argumentieren. Mein Punkt, ist, dass auch mit viel bösem Willen keine 5. Jahreszeit zu erwarten ist, und kein Deppenleerzeichen in "Früh ling".

Benutzereingaben sind aber kein "dümmster Fall", sondern etwas völlig normales, und da sollte man tunlichst testen oder maskieren, aber Benutzereingaben brechen ja nicht von selbst in ein Skript ein.

Ich habe massig Skripte für den Hausgebrauch, wo ein absoluter Pfad vorkommt, die

1

PFAD=/dies/zum/Beispiel 

enthalten, und sträube mich zu sagen es wäre sauberer dies zu quoten. Im Gegenteil - das ist für mich Cargo-Cult-Programmieren - das anwenden eines Musters welches man gesehen, aber nicht verstanden hat. Gut - Du hast es verstanden, und willst es dennoch benutzen, und von mir aus. Aber wenn man es immer so zeigt, auch in derart harmlosen Fällen, dann zeigt man den Anfängern eben nicht wozu die Quotes da sind.

Man kann dann Quotes wie ein Dogma unterrichten, aber hat ständig Ärger mit Häretikern wie mir, und säht m.E. Unsicherheit, weil die Leute, die es lernen, u.U. falsche Vorstellungen entwickeln, wann man Quotes braucht und wieso ('Immer wenn es keine Zahl, sondern etwas Stringartiges ist').

Am besten ist m.E. die Frage im Kopf des Lesers zu provozieren, wieso mal gequotet wird und mal nicht. Findet er selbst die Antwort ist er stolz auf seine Leistung, und merkt es sich am ehesten.

Zu POSIX: Richtig. Der Hintergedanke, den ich hatte, war: „Wenn ich ein Skript schreibe, /bin/sh als Shebang verwende und das ein Link auf die Dash ist, kann ich mir dann automatisch sicher sein, dass das Skript dann POSIX-konform ist, wenn es funktioniert?“

Insofern war meine Formulierung „sehr nahe am POSIX-Standard“ von „oben“ her gedacht: Was POSIX fordert, ist drin, aber wieviel drumherum kann die Shell noch?

Aber dieser Ansatz ist ohnehin blauäugig, kommt überhaupt nicht zum Ausdruck und der Satz in der Box total missverständlich. Ich hab’ den Halbsatz jetzt aus der Box rausgenommen, sodass es nur noch ein allgemeiner Hinweis auf die „Dash in Ubuntu“-Thematik ist.

Aus deinem Beispiel lese ich jedenfalls heraus, dass die Bash nur konfliktierendes Verhalten abstellt, wenn sie als /bin/sh aufgerufen wird. Zumindest verstehe ich den Standard so, dass time kein Shell Builtin ist, insofern dürfte die Bash da nicht ihr Builtin verwenden, sondern müsste wie die Dash auf etwas externes (/usr/bin/time oder so) zurückgreifen.

Kann mich bei der Interpretation aber auch irren. Hab’ jetzt nicht recherchiert, ob „Utilities“ extern sein müssen oder nicht…

Zu Quoting: Hmm, so abwegig klingt das gar nicht. Langsam gerate ich ins Wanken. 😉

Den simplen Pfad hätte ich außerdem vermutlich auch nicht gequotet, ohne groß darüber nachzudenken – „ist ja klar“. Und spätestens damit wär’s inkonsistent.

Vielleicht so: In konkreten Beispielen mit konkreten Werten, wo wirklich keine Quotes notwendig sind, lassen wir sie weg. Aber bei allgemeinen Aussagen wie „mit echo ${array[2]} kann man ein Element ausgeben“ setzen wir sie. Denn je nach Wert des Elements kann auch etwas anderes ausgegeben werden.

Andererseits: Wenn erst einmal ein Abschnitt im Guide ist, der Quoting sauber erklärt hat, erübrigt sich das. Dann sollte der Leser wissen, dass seine Ausgabe nicht mit dem Inhalt übereinstimmen muss.

(Es sei denn, jemand liest den Artikel nicht in Gänze und beschwert sich dann, dass er falsch sei. Aber davon sollte man wohl besser nicht ausgehen.)

Mit dem Quoting ist es etwas diffizil. Was ich privat mache geht ja niemanden was an, deshalb posaune ich es hier nochmal raus: Ich bin da nachlässig. ☺

In Beispielen setze ich sie da, wo sie sein müssen (ist ja logisch). Da, wo sie nicht sein müssen lasse ich sie auch mal weg,

Wenn der User ein Skript auf ein Verzeichnis loslässt, dann kann es sein, dass er weiß, dass da keine heiklen Dateinamen drin sind, und Ungequotetes in Ordnung ist, kann aber auch sein, dass er nicht weiss, dass er Quoting braucht. Wenn aus dem Kontext nicht klarwird was los ist, dann befürworte ich Hinweise/Warnungen.

Was ich nicht befürworte sind überzogene Behauptungen wie "muss, muss immer, soll immer", oder dass man Neulinge korrigiert ohne zu erläutern, als sei es objektiv falsch. Dass man eher zuviel quotet als zuwenig ist aber ganz richtig.

Ein ähnlicher Fall ist häufig bei find mit name/iname zu beobachten. Der User sagt er sucht nach "png"-Dateien, und als Beispiel kommt 'find -iname "*.png"', als habe der User gesagt 'png und PNG'-Dateien, bzw. als wüßte man, dass der User von der Unterscheidung nichts weiss. Naja - vielleicht doch nicht so ähnlich. ☺