staging.inyokaproject.org

Ausgaben in eine Variable schreiben¶

Befehlssubstitution heißt hier das Zauberwort. Damit ist es möglich, die Ausgaben eines beliebigen Befehls in eine Variable zu schreiben. Ein Beispiel soll hier zeigen, wie man z.B. die Namen der Dateien im Homeverzeichnis in eine Variable einliest.

1 2 3 4 5 6 7 8 9

#!/bin/bash #Ausgaben in Variable schreiben #Variablendefinition suchwort="' player'" liste="$(apropos "$suchwort" )" echo " Player-Liste:" echo "$liste"

Wie man sieht, wird alles zwischen $( und ) stehende als Befehl ausgeführt und das Ergebnis zurückgeliefert. Somit gelangen die erhaltenen Daten dann durch die Zuweisung in die Variable $liste. Danach werden die so gewonnenen Daten im Falle dieses Beispiels dann einfach allesamt auf einmal ausgegeben durch echo. Sie lassen sich so aber auch sehr gut über eine Schleife abarbeiten, dazu aber später mehr.

Hinweis:

Es gibt eine alternative Schreibweise zu diesem Operator, die so genannten Backticks `: NAME="whoami". Der Einsatz empfiehlt sich aber nur bei kurzen Befehlen, da sonst der Quellcode leicht unleserlich wird.

Da scheint mir aber irgendwas schiefgegangen zu sein.

Erst ist von Dateien im Homeverzeichnis die Rede, dann kommt aber etwas mit ' player'. Das Beispiel funktioniert aber nicht - ich vermute ein paar Quotes zuviel:

suchwort="' player'"
liste="$(apropos "$suchwort" )"
echo $liste

liefert bei mir gar nichts, dagegen:

apropos player
gxine (1)            - ein GTK/GNOME Frontend f(:ur den xine Video-Player
gxine_client (1)     - Der gxine Video-Player Kommandozeilen-Client
aplay (1)            - command-line sound recorder and player for ALSA soundcard driver
arecord (1)          - command-line sound recorder and player for ALSA soundcard driver
gmplayer (1)         - movie player

und noch einige Player mehr.

Bei den Backticks/whoami ist wohl nur das Wiki-Quoting schiefgegangen.

Danke, das Detail war mir durch die Lappen gegangen.

Die Backticks waren übrigens gar nicht von mir, die waren vorher schon kaputt.
(ich würde die in einer Anfängerveranstaltung sowieso weglassen ...)

- und korrigiert. -

track

track schrieb:

Auch dass noch noch immer die externen Funktionen test und [ anstelle der mächtigeren internen Funktion [[ verwendet wird, gehört dann dabei korrigiert. Das entspricht nun wirklich nicht heutigen Standards und Empfehlungen.

Aber bitte bei Umfangreichen Änderungen ein Baustelle erbitten. ok?

Das Playerbeispiel überzeugt mich didaktisch noch nicht. Die Verwendung einer Variablen hat mit dem Beispiel nichts zu tun, und die vielfachen Anführungsstriche verschleiern, wo wirklich Anführungsstriche nötig sind:

liste=$(apropos player)
echo "$liste"

Ansonsten sind das ja umfangreiche Erweiterungen, tolle Sache!

Nee. das Problem ist, wenn Du nach "player" suchst, kommen die ganzen sinnlosen "multiplayer game" usw. mit.
Deshalb brauchte ich " player" mit Leerzeichen.
Und ich hoffe mal, dieses Detail geht im Grundsatz "besser immer quoten" sowieso unter. Dann ist es auch nicht so wichtig.

Mir war halt nicht klügeres eingefallen, was einem einigermaßen grünen Einsteiger wenigstens einigermassen nahe liegt.
(Profibeispiele würden eh nur abschrecken, da hätte ich ja "lspci" bringen können 😛 )
Bei dem "$(ls ... )" wollte ich ja nun definitiv nicht bleiben.

Aber didaktisch wäre da sowieso noch soooooooooo viel zu machen ....

track

Aus aktuellem Anlaß nochmal draufgesehen. (Ein User beschwerte sich, dass ein Beispiel nicht funktioniere).

Kleine Änderungen habe ich schon mal durchgeführt.

Folgende Schwäche harrt nach wie vor der Bearbeitung: track schrieb:

Auch dass noch noch immer die externen Funktionen test und [ anstelle der mächtigeren internen Funktion [[ verwendet wird, gehört dann dabei korrigiert. Das entspricht nun wirklich nicht heutigen Standards und Empfehlungen.

Das einzelne [ ist ein externes Programm, soviel weiß ich, und kann mir so merken, dass man daher das interne [[ verwenden soll. Soweit eine andere Begründung, neben der Mächtigkeit.

Im Detail zu prüfen, ob alle Beispiele stur nach Schema F zu ändern sind wäre aber nötig, soweit ich weiß - im Kopf habe ich nicht, wo die Unterschiede liegen.

user unknown schrieb:

Das einzelne [ ist ein externes Programm, soviel weiß ich, und kann mir so merken, dass man daher das interne [[ verwenden soll. ...

Ja, hatte ich auch erst gedacht. - aber irgendwann bin ich bei einer Diskussion im Shell-Forum vom Gegenteil überzeugt worden. Offenbar sind beide als interne Funktionen vorhanden, aber eben nur [ auch als externes Programm:

track@lucid:~$ type [
[ is a shell builtin
track@lucid:~$ type [[
[[ Ist ein reserviertes Schlüsselwort der Shell.
track@lucid:~$ which [
/usr/bin/[
track@lucid:~$ dash
$ type [
[ is a shell builtin
$ type [[ 
[[: not found

Von daher ist der zitierte Satz von mir damals überholt.
Heute neige ich eher dazu, wegen der dash- Kompatibilität sowas wie [ "$x" = "" ] zu verwenden. (ja, mit einem "=" ... auch wenn das so eine ekelige Eigenheit der Shell ist)

LG,

track

OK, wenn man es so oder so machen kann, dann lassen wir's wie's ist, schlage ich vor.

Servus,

im Abschnitt zur Shebang wird empfohlen, „wo immer möglich“ /bin/sh zu verwenden, auch wenn die Dash „nicht alle Funktionen der Bash“ unterstütze. Das halte ich aus drei Gründen für problematisch:

1. Das ist ein Anfänger-Guide. Weiß ein Anfänger, wann es möglich ist? Zweifelhaft. Die Empfehlung verleitet aber dazu, halt einfach /bin/sh zu setzen, ohne groß darüber nachzudenken.

2. Die Dash unterstützt so gut wie gar keine Funktionen der Bash. Meines Wissens nach kann die Dash nur ganz knapp mehr als von POSIX gefordert – die Bash hingegen kann tausend Dinge zusätzlich. Der Satz im Wiki ist nicht falsch, aber sehr missverständlich, denn er klingt nach: „Die Dash kann das meiste, was die Bash kann, aber eben nicht alles.“

3. Es wird Geschwindigkeit als Grund angegeben, /bin/sh zu nehmen. Ich behaupte, dass es in der Mehrheit der Fälle für die Geschwindigkeit wirklich keinen Unterschied macht. Portabilität wäre hier ein besserer Grund, finde ich.

Alternative Vorschläge:

1. Deutlicher auf die Unterschiede zwischen den Shells eingehen und auf die Konsequenzen der Wahl einer bestimmten Shebang. Es muss klar werden, dass /bin/bash, /bin/dash und /bin/sh drei unterschiedliche Dinge meinen und der Leser sollte danach eine grobe Vorstellung davon haben, wann er was wählen muss/sollte. So in etwa die Richtung, wie ich es hier hatte (die Benutzerseiten sollen ja aufgeräumt werden, daher komme ich darauf 😉). Ich behaupte nicht, dass das perfekt ist, aber es verdeutlicht vielleicht etwas besser, was ich meine.

2. Den Kasten streichen, an anderer Stelle näher darauf eingehen und statt Kasten einen Link dahin setzen. Schließlich ist der Absatz, um den es da geht, direkt unter der Überschrift „Das erste Skript“ und ich kann nachvollziehen, dass da lange Abhandlungen über die Shebang vielleicht nicht dienlich sind.

Ich tendiere im Moment eher zu Variante 2.

Übrigens, aber ich glaube, das hattet ihr schonmal: Die Beispiele mit den Arrays unten, da sollten Dinge wie „echo ${array[@]}“ dringend gequotet werden. Und ein Wort dazu, warum. Sowieso fehlt in dem Artikel imo noch eine ausführlichere Erklärung zu Quoting oder zumindest Links.

Wenn keine Einwände kommen, fange ich die Tage mal an, etwas rumzubasteln. ☺

Hallo,

prinzipiell hast du Recht. Bzw.: Welchen Sinn hat es, BEWUSST ein falsches She-Bang zu setzen? Gar keinen...

Der Artikel heißt Bash-Skipting Guide für Anfänger, ergo ist /bin/bash richtig.

Die Gründe, warum Ubuntu (unf AFAIK inzwischen auf Debian) Dash als Standardshell nehmen sind im Rahmen des Artikels völlig unerheblich. Das meiste passiert ja so wie so in der interaktiven Shell - und die ist ja auch bei Ubuntu nach wie vpr Bash. ☺

Gruß, noisefloor

Ich begrüße das mehrfach.

• a) Überhaupt die Zielrichtung festzulegen, vor dem loslegen. ☺

• b) Ich würde darauf hinzuweisen, dass das # alleine nur aber bereits besagt, dass es ein Kommentar ist, und dass /bin/bash oder /bin/squash ein Pfad ist, bzw. der Pfad zum Programm sein muss.

• c) Ich würde empfehlen /bin/bash zu verwenden, denn denen, für die sich etwas anderes empfiehlt, muss man eh ein 'für Fortgeschrittene' empfehlen. Erstens sind das professionelle Administratoren, die Scripte schreiben, die vielleicht von Linux auf Solaris oder ein anderes Unix portiert werden - da ist es sinnvoll sich an den Posix-Stadard zu halten, da kommt auch m.W. die Praxis der Empfehlung her, und da ist sie bestens aufgehoben. Aber auf dem Desktop sehe ich keinen Sinn darin die dash zu verwenden, oder den POSIX-Standard zu erlernen. Vielleicht kann man einen Satz dazu aufnehmen, weil diese POSIX/sh-Empfehlerei weit verbreitet ist; damit die User das einordnen können.

• Im S&P-Bereich wird gelegentlich dazugesagt, welche Shell etwas kann oder nicht - v.a. wenn die Leute etwas empfehlen, was die bash nicht kann, z.B. die zsh. Wenn nichts dazu gesagt wird ist es fast immer bash oder sh-Style. Ich selbst habe die Unterschiede nicht im Kopf, und ich glaube damit bin ich nicht alleine.

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.

Sowieso fehlt in dem Artikel imo noch eine ausführlichere Erklärung zu Quoting oder zumindest Links.

Absolut!

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 

Ich habe nicht die ganze Seite gelesen, d.h. meine Kritik bislang besagt nicht, dass ich die Seite ansonsten gutheiße. ☺

Insbesondere ganz unten das:

Born again shell

kann ich nicht gutheißen. Das ist doch keine Wiedergänger/Zombie-Shell, sondern die Bourne again shell.

die Benutzerseiten sollen ja aufgeräumt werden

Ups - ich bin gar nicht angeschrieben worden. ☺ Gibt es da einen Thread?

Hallo,

[off-topic]

Ups - ich bin gar nicht angeschrieben worden. ☺ Gibt es da einen Thread?

Nein, aber eine Ikhaya-Meldung. Deine Seite ist aber (noch?) nicht auf der schwarzen Liste 😉 [/off-topic]

Gruß, noisefloor

noisefloor schrieb:

Nein, aber eine Ikhaya-Meldung.

Danke.

Deine Seite ist aber (noch?) nicht auf der schwarzen Liste 😉

Ja, man merkt, ich werde alt. ☹

😉

@Vain

2-3 Dinge hatte ich noch.

Die Frage, die ich so wichtig fand, habe ich gar nicht näher behandelt: Wer ist Adressat der Seite?

Ich denke

• alle Ubuntuuser könnten (wenn auch nicht sollen) ermuntert werden, die Shell hie und da zu verwenden.

  • Um herauszufinden, ob man damit dies und jenes vereinfachen kann.

  • Um herauszufinden, ob man damit dies und jenes automatisieren kann.

  • Weil Programmieren eine grundlegende Kulturtechnik ist, und Medienkompetenz in erster Linie immer bedeutet, dass man die Technik als Produzent beherrscht, oder schonmal ein wenig dran geschnuppert hat, und damit einmal den übertriebenen Respekt *) verliert, und zum anderen Einsichten gewinnt, wie die ganze Kiste überhaupt funktioniert.

  • weil es einfach Spaß macht die Shell zu verwenden

• spezielle Gründe die Shell kennenlernen zu wollen

  • Systemscripte verstehen zu wollen, wie sie in /etc/init.d stehen, oder in /etc/Network/if-up.d und ähnlichen

  • wiederkehrende Aufgaben von Befehlssequenzen aus 3-4 Befehlen als Skript speichern

  • größere Souveränität, wenn es darum geht Informationen für Bugreports oder Fragen zu sammeln, und zur Diagnose bei Problemen

    • Beispiele

      • lspci, lsusb, lshw

      • logfile-Auswertung

      • apt-get und Anverwandte

      • ping, nmap, ifconfig, iwconfig, route,

      • ps, free, lsmod, modprobe, top, htop

      • ls, df, du, cd, cp, mv, cat, type, file, date ...

      • coreutils, textutils, xyutils

      • ...

• Gruppen, die manchmal adressiert werden, die ich aber allenfalls am Rande berücksichtigen würde:

  • Windowsumsteiger haben i.d.R. auch keine Scripterfahrung, wenn doch, haben jüngere vielleicht eher Erfahrung mit Powershell und wsh, ältere Semester mit cmd.exe/command.exe/command.com. Eine kl. Tabelle für einfache Übersetzungen (#/rem, cat/type, rm/del, ...) könnte man ja anbieten. Als dogmatisch-bornierter Egozentriker würde ich das aber unter die Überschrift setzen: "Diese Tabelle hilft Euch, Eure Skripte für Windows zu übertragen", so als gäbe es mehr User, die mit Linux beginnen, und dann irgendwann Windows kennenlernen, als umgekehrt. Keineswegs würde ich die Seite auf Windowsumsteiger zuschneiden, oder auch nur oft Windows erwähnen.

  • Bereits zuvor erwähnt: Administratoren in Serverräumen, die nebenbei Solaris und AIX-Maschinen warten, und die man POSIX-konform erziehen würde, würde ich nicht primär adressieren.

  • Programmierer, die bereits for-Schleifen, Funktionen usw. von anderen Sprachen kennen, würde ich auch nicht als primäre Zielgruppe begreifen. Diese können fast alle Englisch, und haben daher wenig Mühe im Netz gezielt nach den Informationen zu suchen, von denen sie ahnen, dass es sie gibt.

So, wie erwartet und befürchtet habe ich jetzt die 2 anderen Punkte vergessen. ☺

*) Ich kann mir die Gewißheit, mit der Shellfragen immer wieder als 'fortgeschritten' oder 'für Experten' bezeichnet werden nicht erklären, außer ich nehme an, dass hier eifersüchtige Priester ihre Pfründe bewachen, also in erster Linie das Ansehen, welches sie genießen, weil sie 2 Wörter, 2 Buchstaben und 3 Zahlen in der richtigen Reihenfolge und mit der erwarteten Mindestanzahl an Blanks dazwischen auf der Tastatur eintippen können, ohne ins Handbuch zu schauen.

Hallo,

dem stimme ich in allen Punkte zu (bis auf einen - s.u.). Es wird Linux-Einsteigern gerne gesagt: "Die Shell ist dein Freund". Diese Seite ist also sowas wie die Partnervermittlung für den Erstkontakt. 😉

Eine Punkt würde ich anders machen: Die Übersetzung "Win → Linux" würde ich auf einer Unterseite auslagern. Wie du ja richtig erwähnst können wir wohl pauschal davon ausgehen, dass die Zielgruppe dieser Seite auch unter Win die Kommandozeilen nicht genutzt hat, deshalb braucht's das im Artikel selber eher nicht.

Die Idee für die Übersetzung finde ich trotzem gut. ☺

Gruß, noisefloor