staging.inyokaproject.org

Erster Entwurf für den „Quoting“-Abschnitt ist drin. Gar nicht so einfach, das langsam, sauber und auch noch anschaulich zu erklären. Bitte reichlich Kritik. ☺

Ich hab dafür den Abschnitt „Variablen“ in zwei Teile getrennt. Vor Teil 1 ergäbe Quoting IMO keinen Sinn und danach wäre es zu weit hinten. Also dazwischen eingeschoben.

• Stern: Gibt es eine generelle 'passe auf Zeichenketten'-Funktion?

  • ist: Möchte ich also zum Beispiel den Stern von seiner Bedeutung „passe auf alle Zeichenketten“ (was im folgenden Beispiel auf „alle nicht-versteckten Dateien im aktuellen Verzeichnis“ hinausläuft) entbinden, dann muss ich Anführungszeichen um ihn herum setzen.

  • soll: Möchte ich also zum Beispiel den Stern von seiner Bedeutung „passe auf alle Namen nicht-versteckter Dateien im aktuellen Verzeichnis“ entbinden, dann muss ich Anführungszeichen um ihn herum setzen.

• locale de: Die ist doch standardmäßig DE, und müßte per LANG= wenn, dann auf etwas anderes gesetzt werden (en_US, z.B.) - ich würde es so umkehren, dass es beim User per Default ist, wie im Wiki.

Ansonsten finde ich es sehr anschaulich. Etwas hervorgehoben werden sollte m.E. noch, dass die Shell, in der man das eintippt, die Auflösungen vornimmt, bevor ein Programm etwas zu sehen bekommt, so dass man, ohne 'cmd' zu kennen sagen kann, was cmd zu sehen bekommen wird:

1

cmd * -foo='?.txt' \; bar ?.txt

user unknown schrieb:

• Stern: Gibt es eine generelle 'passe auf Zeichenketten'-Funktion?

Ich dachte da ans Matching bei ==, wo der Stern meines Wissens nach nichts mit Dateinamen zu tun hat. Zumindest, wenn er auf der rechten Seite steht, bei der linken Seite bin ich mir gerade unsicher.

              When  the == and != operators are used, the string to the right
              of the operator is considered a pattern and  matched  according
              to  the  rules  described below under Pattern Matching.

$ ls
$ touch bar
$ if [[ bar == * ]]; then echo passt; else echo nein; fi
passt
$ if [[ foo == * ]]; then echo passt; else echo nein; fi
passt
$ rm bar
$ if [[ foo == * ]]; then echo passt; else echo nein; fi
passt
$ if [[ foo == f* ]]; then echo passt; else echo nein; fi
passt
$ if [[ foo == g* ]]; then echo passt; else echo nein; fi
nein

• locale de: Die ist doch standardmäßig DE, und müßte per LANG= wenn, dann auf etwas anderes gesetzt werden (en_US, z.B.) - ich würde es so umkehren, dass es beim User per Default ist, wie im Wiki.

Hmmmmmmmmm, okay, bei Einsteigern, die einen deutschen Bash-Guide lesen, wird das wohl in den meisten Fällen so sein. Nicht dran gedacht, mein System ist englisch.

Gibt es denn en_US (in Ubuntu) immer?

Vielleicht fällt mir da auch noch ein besseres Beispiel ein, was nicht so systemabhängig ist.

Etwas hervorgehoben werden sollte m.E. noch, dass die Shell, in der man das eintippt, die Auflösungen vornimmt, bevor ein Programm etwas zu sehen bekommt

Okay, sollte jetzt etwas deutlicher sein.

Sollte man da Vergleiche zu DOS ziehen? Soweit ich das noch weiß, ist das da anders und die Programme müssen das Globbing selbst machen. Kann mich aber auch irren.

Hier ist noch eine Anregung: http://mywiki.wooledge.org/BashFAQ/050 (bin zufällig drüber gestolpert. Dieser Tage hat es die ganze Welt mit Quoting).

Vain schrieb:

user unknown schrieb:

• Stern: Gibt es eine generelle 'passe auf Zeichenketten'-Funktion?

Ich dachte da ans Matching bei ==, wo der Stern meines Wissens nach nichts mit Dateinamen zu tun hat. Zumindest, wenn er auf der rechten Seite steht, bei der linken Seite bin ich mir gerade unsicher.

Bei case-Statements gibt es das auch, aber ich meine das ist keine Gemeinsamkeit, sondern nur eine Ähnlichkeit. Dass es keinen gemeinsamen Code gibt, der auf Text und Dateinamen matcht, sondern dass es 2-mal ähnliche Aufgaben gibt, für die es aber eigenen Code gibt. Habe es aber weder nachgesehen, noch mir einen Test überlegt, und denke auch, ehrlichgesagt, erstmalig etwas gründlicher darüber nach. ☺

• locale de: Die ist doch standardmäßig DE, und müßte per LANG= wenn, dann auf etwas anderes gesetzt werden (en_US, z.B.) - ich würde es so umkehren, dass es beim User per Default ist, wie im Wiki.

Hmmmmmmmmm, okay, bei Einsteigern, die einen deutschen Bash-Guide lesen, wird das wohl in den meisten Fällen so sein. Nicht dran gedacht, mein System ist englisch.

Gibt es denn en_US (in Ubuntu) immer?

Tja - gut möglich, dass ich extra, neben den de- die en-Varianten ausgewählt habe. Aber LANG=C sollte immer gehen. Hast Du de_AT installiert? ☺

1
2
3

LANG=de_DE.UTF-8 date +%B -d-3month ; env LANG=de_AT.UTF-8 date +%B -d-3month
Januar
Jänner

Sollte man da Vergleiche zu DOS ziehen? Soweit ich das noch weiß, ist das da anders und die Programme müssen das Globbing selbst machen. Kann mich aber auch irren.

Ich würde sagen: Nein. Kennst Du Dich in der cmd.exe-Shell (cmd32.exe, command.com) derartig aus? Wer sich da auskennt, der fuchst sich auch bei Linux selbst rein, weil er das Problmen im Prinzip schon kennt.

user unknown schrieb:

Hier ist noch eine Anregung: http://mywiki.wooledge.org/BashFAQ/050 (bin zufällig drüber gestolpert. Dieser Tage hat es die ganze Welt mit Quoting).

Für Quoting insbesondere auch das dort verlinkte WordSplitting.

(Der ganze Kram ist ja schon an tausend Stellen schön beschrieben. Gibt es tatsächlich noch keine deutsche Sammelstelle außer hier bei uu.de? Ich kenne auch alles nur auf englisch… Es wäre so schön, wenn man statt Reproduktion einfach irgendwo hinlinken könnte. ☺)

Bei case-Statements gibt es das auch … und denke auch, ehrlichgesagt, erstmalig etwas gründlicher darüber nach. ☺

Dito. Ob da derselbe Code verwendet wird, weiß ich nicht. Dass die beiden zumindest sehr nahe beeinander sind, schloss ich aus dem Verweis auf „pattern matching“ da im Handbuch.

Mit if und case im Hinterkopf wäre es jedenfalls etwas missverständlich, den Stern als dateinamensbezogen einzuführen. Immerhin hat man bei einem if / case einen unge-quote-teten Stern da rumstehen und da läge die Vermutung dann nahe, dass er irgendwas mit Dateien macht.

Tja - gut möglich, dass ich extra, neben den de- die en-Varianten ausgewählt habe. Aber LANG=C sollte immer gehen. Hast Du de_AT installiert? ☺

C ist eine Möglichkeit. So habe ich das jetzt mal umgebaut, außerdem zur Sicherheit $LC_ALL statt $LANG. Das ist dann halt nicht mehr so anschaulich wie konkrete Locales, dürfte aber noch am ehesten beim Ausprobieren den gewünschten Effekt zeigen.

Ich würde sagen: Nein. Kennst Du Dich in der cmd.exe-Shell (cmd32.exe, command.com) derartig aus? Wer sich da auskennt, der fuchst sich auch bei Linux selbst rein, weil er das Problmen im Prinzip schon kennt.

Agreed. ☺

(Ein echo *.txt auf dem Uni-Rechner zeigt jedenfalls *.txt an und nicht die Dateien im Verzeichnis. Aber das müsste ein Fachmann beantworten. Ich muss die cmd auch nur alle Jubeljahre mal benutzen.)

(Ein echo *.txt auf dem Uni-Rechner zeigt jedenfalls *.txt an und nicht die Dateien im Verzeichnis. Aber das müsste ein Fachmann beantworten. Ich muss die cmd auch nur alle Jubeljahre mal benutzen.)

Ich erinnere mich, dass man nur am Ende matchen kann, aber bei Name und Erweiterung getrennt, also

ls fo*.b* geht, *oo.*ar geht nicht. Inzwischen dürfen die Dosser aber auch mehr als einen Punkt setzen, nichtwahr, und womöglich hat man die Regeln daher gelockert?

Was die Sammelstelle auf Deutsch betrifft - das werden wohl wir. Ich habe zuletzt diverse Seiten von Computerzeitschriften gefunden, wo wohl als Artikelbegleitung Code und Text im Netz war, mit veralteten und nicht empfehlenswerden Konstrukten, seit Jahren online und nicht korrigiert. Wenn bei uns was entsteht, dann wird es auch gepflegt, dagegen.

„Arrays belegen“ und „Arrays auslesen“ etwas erweitert. ☺

Offene Fragen:

• Assoziative Arrays noch dazutun? Gibt es aber erst in der Bash 4.

• Der Abschnitt „Beispiel für ein Array“ macht mir etwas Bauchschmerzen. Ich habe jetzt davor schon viele Beispiele reingebracht. Das halte ich auch für notwendig, da ich nicht überall schreiben wollte: „Dies und das geht so. Beispiel siehe unten.“ Der Abschnitt „Beispiel für ein Array“ wirkt jetzt auf mich ein bisschen redundant.

• Auf $IFS genauer eingehen? Immerhin ist es ein Anfänger-Guide und keine komplette Referenz … oder?

Generell mal eine Frage: Der alte Artikel ging wesentlich langsamer vor. Ich habe manchmal den Eindruck, dass mein Geschreibsel zu schnell in die Vollen geht und den Leser vielleicht überlastet. Täusche ich mich da?

Wenn ich mal als Bislang-Noch-Nie-Bash-Skripter, also als Anfänger anmerken darf: nach neugierigem Lesen bin ich schon ziemlich am Anfang ausgestiegen.

• welcher Editor unterstützt Syntachervorhebung?

• Mein_Skript oder Skriptname? verwirrt wenn die Bezeichnung nicht einheitlich ist

• "welchen man der Umgebungsvariablen $PATH bekannt macht" Hä? wie geht das?

• Shebang Geschichte: verwirrend. Da scheinen mir Details im Text, die der Anfänger nicht braucht, die nur irritieren.

• Anführungszeichen ist ' und nicht ", wechselt aber im Text

• Ausgeben bedeutet in der Konsole anzeigen

• Begriff Maskierung taucht unerklärt auf

Weiter bin ich nicht vorgedrungen ☹

Hallo,

"zu schnell" ist es IMHO nicht. Letztendlich muss man ja auch einen Mittelweg aus "verständlich" und "hinreichend Inhalt" finden. Und viel länger muss der Artikel auch nicht werden...

Der Artikel soll IMHO in erster Linie neugierig machen und einen (kleinen?) Einblick geben. Wer sich näher mit Shell-Programmierung bzw. Bash-Skripten beschäftigt, der braucht so wie so ein Buch oder ein ausführliches Tutorial - davon gibt es ja genug im Netz.

Eine Anmerkung habe ich zum Abschnitt "Array":

Da steht

Arrayname[n]="Wert" 

Das ist IMO missverständlich, weil man (inkl mir 😀) es erst mal als "Arraynamen" (also Mehrzahl) liest.

Besser wäre wohl:

Arrayname[N]="Wert" 

frustschieber schrieb:

welcher Editor unterstützt Syntachervorhebung?

Der Link auf Editoren ist gesetzt, dass reicht IMHO - sonst hätte man Redundanz 😉

frustschieber schrieb:

Shebang Geschichte: verwirrend. Da scheinen mir Details im Text, die der Anfänger nicht braucht, die nur irritieren.

Jain - siehe Diskussion ist weiter oben. /bin/sh als Shebanng vor Bash-Skripte setzen ist nun mal ein populärer Fehler. Man könnte nur überlegen, ob man nicht einen eigenen Artikel zum Shebang schreibt. Der Shebang kommt ja auch in den Artikel zu z.B. Python oder Perl. Wobei man dort - im Gegensatz zu sh und bash und dash und ... eigentlich keinen echten Fehler bei der Shebang machen kann.

Gruß, noisefoor

Moin,

frustschieber schrieb:

• Mein_Skript oder Skriptname? verwirrt wenn die Bezeichnung nicht einheitlich ist

good point. Und wo wir dabei sind: „skriptname.sh“ oder nur „skriptname“? Es spielt ja keine Rolle. Für Einsteiger ist es mit Erweiterung vielleicht einfacher, keine Ahnung. Sollte aber auch konsistent sein.

Sowas ähnliches gibt es unten aber nochmal. Einmal „Arrayname“ und einmal „array“. Ich wäre ja fast für „arrayname“, also kleingeschrieben – „array“ liest sich (zumindest für mich) wie ein Schlüsselwort.

Oder halt „foo“…

• "welchen man der Umgebungsvariablen $PATH bekannt macht" Hä? wie geht das?

Naja, wie das geht, steht im Link hinter $PATH. Aber ist ~/bin bei Ubuntu nicht standardmäßig im Path? Falls ja, sollte man das wohl als Speicherort für eigene Skripte empfehlen und könnte die Geschichte mit $PATH eventuell rauslassen.

• Anführungszeichen ist ' und nicht ", wechselt aber im Text

Hum, das ist schwierig. Ja, ist etwas unklar. Ich kenne allgemein „Anführungszeichen“ eigentlich als " oder '. ☺ In meinem Text hatte ich das Wort dann ohne nähere Beschreibung genutzt, wenn es eigentlich keine Rolle spielt – nur im Zweifelsfall „doppelt“ oder „einfach“ dazu. Tatsächlich aber war das erste Auftreten von „Anführungszeichen“ im Zusammenhang mit ', also einfachen Anführungszeichen.

Bei diesem ersten Auftreten hab ich jetzt mal doppelte Quotes gesetzt. Ist das klarer?

• Ausgeben bedeutet in der Konsole anzeigen

Ja, tut es. Oder nicht? Was hättest du erwartet?

• Begriff Maskierung taucht unerklärt auf

Okay, nachgetragen.

Weiter bin ich nicht vorgedrungen ☹

Nur interessehalber: Hast du noch nie mit der Bash Skripte geschrieben oder noch nie programmiert?

noisefloor schrieb:

Eine Anmerkung habe ich zum Abschnitt "Array":

Da steht

Arrayname[n]="Wert" 

Das ist IMO missverständlich, weil man (inkl mir 😀) es erst mal als "Arraynamen" (also Mehrzahl) liest.

Arrr! „n“ oder „N“ finde ich eigentlich ziemlich falsch. 😀 Ist „n“ und erst recht „N“ nicht immer die Gesamtanzahl und „i“ ein einzelnes? ☺

Vain schrieb:

good point. Und wo wir dabei sind: „skriptname.sh“ oder nur „skriptname“? Es spielt ja keine Rolle. Für Einsteiger ist es mit Erweiterung vielleicht einfacher, keine Ahnung. Sollte aber auch konsistent sein.

Wenn der User konsistent Scripte als foo.sh speichert, dann kann er leicht per globbing filtern:

1

ls *.sh

Sowas ähnliches gibt es unten aber nochmal. Einmal „Arrayname“ und einmal „array“. Ich wäre ja fast für „arrayname“, also kleingeschrieben – „array“ liest sich (zumindest für mich) wie ein Schlüsselwort.

Oder halt „foo“…

Da sind Varianten gar nicht so schlecht - nicht dass die User glauben, 'array' wäre ein Schlüsselwort.

Arrayname[n]="Wert" 

Das ist IMO missverständlich, weil man (inkl mir 😀) es erst mal als "Arraynamen" (also Mehrzahl) liest.

Arrr! „n“ oder „N“ finde ich eigentlich ziemlich falsch. 😀 Ist „n“ und erst recht „N“ nicht immer die Gesamtanzahl und „i“ ein einzelnes? ☺

Nein, nicht immer. i wird oft als (I)nteger, n als (n)ormale Zahl verstanden, aber streng hält sich da eh niemand dran. *Wenn* es mal ein sehr mathematisch/statistisches Problem gibt, dann würde ich N für eine gute Wahl für die Gesamtmenge halten, aber es dafür zu reservieren ...?

Ein paar Löffelchen Senf hätte ich auch noch dazu ...

... Und wo wir dabei sind: „skriptname.sh“ oder nur „skriptname“? Es spielt ja keine Rolle.

Nicht ganz. Ich würde ausdrücklich nur "skriptname" schreiben, ohne Endung. Sonst denken die Neuen, ganz Win..-like, dass Skripte diese Endung haben müssen, oder wenigstens haben sollten. Das fände ich pädagogisch schlecht.

... Ich wäre ja fast für „arrayname“, also kleingeschrieben

+1
Überhaupt sollte es konsequent durchgehalten werden, dass alle eigenen Variablennamen klein (und nur Systemvariablen groß) geschrieben werden. Dann ersparen wir uns manche endlose Diskussion darüber.

... Aber ist ~/bin bei Ubuntu nicht standardmäßig im Path? Falls ja, sollte man das wohl als Speicherort für eigene Skripte empfehlen und könnte die Geschichte mit $PATH eventuell rauslassen.

+1
Rauslassen. Sonst verzettelt man sich.

Arrr! „n“ oder „N“ finde ich eigentlich ziemlich falsch. 😀 Ist „n“ und erst recht „N“ nicht immer die Gesamtanzahl und „i“ ein einzelnes? ☺

Sinnvoller fände ich arrayname[x]="wert" ... Das "x" assoziiert jeder mit "x-beliebiger" Variable, so wie es gemeint ist.
Damit kann man die Details mit "assoziativen" Arrays usw. auch ruhig übergehen, in einem Anfänger-Wiki.

frustschieber schrieb:

• Shebang Geschichte: verwirrend. Da scheinen mir Details im Text, die der Anfänger nicht braucht, die nur irritieren.

+1
Einfach #!/bin/bash als Standard-Shebang einführen, mehr nicht. Im Anfänger-Wiki müssen mehr Details nicht sein.

LG,

track

Servus ☺

track schrieb:

... Und wo wir dabei sind: „skriptname.sh“ oder nur „skriptname“? Es spielt ja keine Rolle.

Nicht ganz. Ich würde ausdrücklich nur "skriptname" schreiben, ohne Endung.

Dagegen. Grund: Auch Linux- (Ubuntu-?KDE-?)Editoren verwenden die Erweiterung als Erkennungsmerkmal des Dateityps. Wenn ich die Datei skriptname mit Kate öffne, erhalte ich keine (automatische) Syntaxhevorhebung, mit Datei skriptname.sh schon.

Sinnvoller fände ich arrayname[x]="wert" ... Das "x" assoziiert jeder mit "x-beliebiger" Variable, so wie es gemeint ist.

+1, oder eben i, weil i eine gängige Zählvariable in Schleifen ist.

Einfach #!/bin/bash als Standard-Shebang einführen, mehr nicht. Im Anfänger-Wiki müssen mehr Details nicht sein.

+1

noisefloor schrieb:

Der Artikel soll IMHO in erster Linie neugierig machen und einen (kleinen?) Einblick geben. Wer sich näher mit Shell-Programmierung bzw. Bash-Skripten beschäftigt, der braucht so wie so ein Buch oder ein ausführliches Tutorial - davon gibt es ja genug im Netz.

Ja, bitte. Bash-Skripting ist nichts Ubuntuspezifisches (auch wenn die Bash nunmal in Ubuntu "voreingestellt" ist) und sollte von daher eigentlich in diesem Wiki nur eine untergeordnete Rolle spielen.

user unknown schrieb:

Was die Sammelstelle auf Deutsch betrifft - das werden wohl wir. Ich habe zuletzt diverse Seiten von Computerzeitschriften gefunden, wo wohl als Artikelbegleitung Code und Text im Netz war, mit veralteten und nicht empfehlenswerden Konstrukten, seit Jahren online und nicht korrigiert. Wenn bei uns was entsteht, dann wird es auch gepflegt, dagegen.

IMHO ist unser Wiki nicht für eine dauerhafte Dokumentation von Bash-Skripting gedacht. Einführung = ok, Doku= nicht ok.

Man möge mich berichtigen, wenn ich mit der Meinung falsch liege.

Gruß
kaputtnik

Ich bin noch nicht durch den ganzen Artikel durch, aber schon mal so weit:

Editor: Da es sich IMO um einen Artikel für Skripting- und nicht für Linux-Anfänger handelt würde ich einfach schreiben:

Zuerst sollte man einen passenden Editor suchen, mit welchem man arbeiten möchte.

"Ausführbar machen" würde ich als "Dateien ausführbar machen" als eigenen Artikel sehen wollen, dann vielleicht einen Zacken ausführlicher. Im hiesigen Artikel dann einfach nur dort hin verlinken. Gibt es da nicht schon einen Artikel zu?

Shebang:

Mir gefällt die Erklärung sehr gut und ich fände es schade, wenn sie ganz verschwinden würde. An dieser Stelle ist es aber in der Ausführlichkeit unpassend, daher einfach nur - wie auch schon von anderen erwähnt:

Ein Bash-Skript wird stets mit der folgenden Zeile - der Shebang (Link zu Artikel Shebang) - eingeleitet:

1

#!/bin/bash

Variablen:

Das sollte auf jeden Fall ein Abschnitt werden - ohne das Quoting dazwischen. Auch wenn ich weiß, dass es in Anfänger-Artikeln bisweilen schwierig ist, die Inhalte in die richtige Reihenfolge zu bringen.

Ich fände folgenden Aufbau geschickter:

1. Ausgabe mit Echo erklären

2. Dann Quoting, wofür ja echo schon ausreicht - auch erst mal ohne Variablen sondern nur mit konkretem Text.

3. Dann Variablen

Dann möchte ich mal aus eigener Erfahrung sagen, dass ich foo...bar gerade in einem deutschsprachigen Artikel vollkommen überflüssig finde, auch wenn das in der IT weit verbreitet ist. Selbst wenn man Englisch Grundkenntnisse hat ist das nicht unbedingt geläufig. Ich würde - auch in dem Sinne, dass man Leute zu aussagekräftigen Variablen-Namen erzieht, in den Beispielen auch einprägsame Namen verwenden.

Will man das nicht, weil man sagt, dass foo...bar in der IT verbreitet ist, dann wenigstens kurz erläutern.

Ich habe anfangs nämlich auch mal gedacht, das seien so eine Art Standard-Variablen.

Die Beispiele würde ich mir noch ein wenig praxisorientierter wünschen, dazu schreib ich aber später dann auch noch mal etwas Konstruktives.

Fortsetzung folgt...

Und damit das nicht falsch rüber kommt: Die alleinige Aufführung von Kritik soll nicht darüber hinwegtäuschen, dass ich großen Respekt vor der bisherigen Arbeit habe! 👍

Schöne Ostern!

Gruß, Martin

Moin,

Shebang: Gegen einen eigenen Artikel hätte ich nichts einzuwenden.

Ausführbar machen: In chmod und Rechte steht was. Was genau sollte zu dem Thema noch gesagt werden? Vielleicht könnte man das aber mit dem (hypothetischen) Shebang-Artikel verbinden und auch auf den Unterschied zwischen „bash foo.sh“ und „./foo.sh“ genauer eingehen mit Bezug auf die Rechte. Naja, nur so eine Idee.

Quoting: Ich finde nicht, dass ein einfaches echo ausreicht, um das zu erklären. An echo kann ich zeigen, was es mit Leerzeichen und dem Stern auf sich hat. Viel mehr aber nicht. Wieso manche Variablen in Quotes eingeschlossen sein sollten und wieso es bei anderen nicht notwendig ist, kann ich daran nicht zeigen. So richtig glücklich bin ich mit dem aktuellen Einschub aber auch nicht.

skriptname vs. skriptname.sh: Ich hätte da prinzipiell denselben Gedanken wie track gehabt. Dass manche Editoren sich auf die Erweiterung verlassen, war mir aber gar nicht so bewusst. Tja, vielleicht einfach einen Hinweiskasten mit „Dateinamen von Skripten benötigen keine besondere Erweiterung wie „.sh“, diese kann also auch entfallen. Einige Editoren verlassen sich aber darauf und bieten Syntaxhevorhebung nur bei passender Dateinamenserweiterung an.“? 😉