Wie steige ich aus der While Schleife aus, ohne das bash Script zu beenden?

SeppJ schrieb:

[ … Geflame über ein Bash Tutorial … ]
#!/bin/[b]sh[/b]

Na super.

Kann mir mal jemand sagen, warum Ubuntu die dash als Standardshell verwendet?
Da ist es ja kein wunder, wenn das Script nicht funktioniert.

JEDE normale Linux Distribution nimmt hier die bash, aber Ubuntu macht's mal wieder komplett anders.

Sehr ärgerlich.

Christoph

Bash Newbie schrieb:

Kann mir mal jemand sagen, warum Ubuntu die dash als Standardshell verwendet?
Da ist es ja kein wunder, wenn das Script nicht funktioniert.

dash soll deutlich schneller sein als bash, das ist der Grund.

Es war aber schon immer so: Wenn du bash-Features verwenden willst, musst du bash als Interpreter verlangen.

Nunja, ich bin davon ausgegangen, dass unter Linux die Bash der Standard wäre.
Für andere Unixe wollte ich keine Shell Scripte schreiben, insofern habe ich mich auf die Bash konzentriert.

Aber wenn man jetzt selbst unter den Linux Distributionen so nen Shell Wildwuchs hat, egal was auch immer der Grund dafür sein mag, dann frage ich mich, ob es dann nicht besser wäre, gleich eine ordentliche Scriptsprache wie Python zu verwenden.

Was kann man denn als kleinsten gemeinsamen Nenner an Shellfunktion erwarten?
Ich denke mal die Bourne Shell, aber die kann doch keine farbige Ausgabe, oder?
Was wäre denn der nächstgrößere gemeinsamme Nenner?

Das mit dem echo -e und der Funktionsdefinition habe ich übrigens lösen können.

Bleibt dann noch der Punkt mit der If Abfrage, die wahr meldet, aber false sein müsste.
Ist das ne dash Eigenheit?

Shade Of Mine

Bash Newbie schrieb:

Nunja, ich bin davon ausgegangen, dass unter Linux die Bash der Standard wäre.
Für andere Unixe wollte ich keine Shell Scripte schreiben, insofern habe ich mich auf die Bash konzentriert.

Wenn du bash scripte erstellst, dann musst du die bash als Interpreter dieser Scripte verlangen. Dafuer ist die erste Zeile im Script ja da.

Wenn du ein Python Script schreibst, dann verlangst du ja auch nicht PHP als Interpreter...

Christoph

Bash Newbie schrieb:

Nunja, ich bin davon ausgegangen, dass unter Linux die Bash der Standard wäre.

Bash war unter Linux nie Standard, soweit ich weiß. Einige Distributionen nehmen bash als Standard-Shell für interaktive Sessions, aber das heißt ja nichts (und macht gar keine Aussage über nicht-interaktive Sessions).

Bash Newbie schrieb:

Aber wenn man jetzt selbst unter den Linux Distributionen so nen Shell Wildwuchs hat, egal was auch immer der Grund dafür sein mag, dann frage ich mich, ob es dann nicht besser wäre, gleich eine ordentliche Scriptsprache wie Python zu verwenden.

Wenn du auf Kompatibilität wert legst, ist ein Shell-Skript eine denkbar ungünstige Wahl. Dann würde ich eher sowas wie Python nehmen.

Es geht ja schon damit los, wie du denn bash forderst in der ersten Zeile des Skripts? Mit #!/bin/bash? Glückssache, denn wer sagt, dass bash in /bin liegen muss? Mit #!/usr/bin/env bash? Soll zuverlässiger sein, ist aber immer noch nicht sicher, ob env an diesem Pfad existiert und ob bash im Pfad liegt. Die sicherste Lösung ist wohl, die Shell-Skripte bei der Installation dynamisch ans aktuelle System anzupassen, d.h. die erste Zeile fürs System passend zu korrigieren.

Elegant und portabel ist was anderes. (Zugegeben, ich kenne keine Distribution, auf der #!/usr/bin/env bash nicht funktioniert.)

Bash Newbie schrieb:

Was kann man denn als kleinsten gemeinsamen Nenner an Shellfunktion erwarten?
Ich denke mal die Bourne Shell, aber die kann doch keine farbige Ausgabe, oder?
Was wäre denn der nächstgrößere gemeinsamme Nenner?

Farbige Ausgabe hat nichts mit der Shell zu tun, das ist eine Sache des Terminals. Je nach Terminal wird es farbig, wenn bestimmte Byte-Sequenzen ankommen, oder auch nicht. Farbige Ausgabe sollte in jedem Fall abschaltbar sein, wenn sie über escape-Sequenzen läuft, denn sonst wird es echt hässlich, die Ausgabe deines Skripts in eine Datei zu speichern.

Würdet ihr mir dieses Buch empfehlen?

"Shell-Programmierung: Das umfassende Handbuch" von Jürgen Wolf

http://www.amazon.de/Shell-Programmierung-umfassende-Handbuch-Galileo-Computing/dp/3836216507/

Wutz

Nein.
Bücher dieses Autors sind Pfusch.
Suche hier im Forum mal nach dem Autornamen.

Wutz

Bash Newbie schrieb:

Und warum ist der Eintrag in diesem Buch falsch:
http://linuxint.com/DOCS/Linux_Docs/openbook_shell/shell_008_000.htm
...
Das tolle Tutorial bzw. Buch behauptet völlig Falsches.

Weil der Autor dieses Buches per se pfuscht.

Wutz

Bash Newbie schrieb:

Nunja, ich bin davon ausgegangen, dass unter Linux die Bash der Standard wäre.
Für andere Unixe wollte ich keine Shell Scripte schreiben, insofern habe ich mich auf die Bash konzentriert.

/bin/sh wird gerne auch von den Autoren der jeweiligen Distribution auf ihren jeweiligen Shell-Favoriten verlinkt, oftmals entspricht /bin/sh also /bin/bash bzw. wie du gemerkt hast, eben dash.
Ein simples

man sh

dürfte erhellend wirken und somit auch deine Konfusionen erklären.

Für bourne(again) Shells liefert die manpage also z.B.

`BASH(1) BASH(1)

NAME

   bash - GNU Bourne-Again SHell

...

Shell Function Definitions

...

   [ function ] name () compound-command [redirection]

          This  defines a function named name.  The reserved word function

          is optional.  If the function reserved  word  is  supplied,  the

          parentheses  are optional.  The body of the function is ...`

was die Shell-Funktionen ausreichend erklären sollte.

tntnet

Also Dein ursprüngliches Skript ist einfach falsch. Das funktioniert weder unter bash noch irgendeiner anderen shell.

Bash und dash sind beide reimplementierungen der bourne shell, die unter Unix unter /bin/sh zu finden sind. Dabei ist bash stark erweitert. Wenn Du kompatibel sein willst, schreibst Du Deine Shell-Skripte für die bourne shell. Dann ist es egal, ob /bin/sh das Original oder bash oder dash oder was auch immer ist. Und mit der bourne shell kommt man sehr weit.

Der Vorschlag, python zu verwenden, ist ziemlich daneben. Nicht überall gibt es python. Sicher auf fast allen Linux-Desktop- oder Server-Systemen. Aber im embedded Bereich, wie beispielsweise OpenWRT, spart man sich python. Und auch die bash. Da ist /bin/sh teil der busybox. Also immer schön bei bourne shell bleiben.

Zu der Diskussion, ob bash irgendwo Standard ist. Ich habe hier fedora und da zeigt /bin/sh auf bash. Bei Debian war das früher auch so, aber die haben irgendwann umgestellt. Dem folgen in der Regel die Debian-basierten Distributionen, wie beispielsweise Ubuntu.

Ich verwende häufig die bash man page, um was nachzuschlagen. Aber die meisten Shell-Skripte, die ich schreibe laufen dann tatsächlich in der originalen bourne shell, da ich auf der Arbeit mit AIX arbeite, was ein Unix ist.

Übrigens ist set -x sehr hilfreich, um Shell Skripte zu untersuchen und zu verstehen. In Deinen Beispielen passieren so ein paar interessante Sachen. Du musst daran denken, dass shells ziemlich einfach gestrickt sind. Das da:

set $bool = true

bewirkt, dass $bool durch den Inhalt von der Variablen bool ersetzt wird. Wenn bool gar nicht gesetzt ist, kommt dann so was raus:

set = true

Das ist dann ein Syntaxfehler.
Das gleiche gilt für

while $true ; do ...

Richtig wäre:

#!/bin/sh
bool=true
while [ "$bool" = true ] ; do
  echo Hi
  bool=false
done
echo Ende

Bei der Zuweisung ist es auch wichtig, keine Leerzeichen zu verwenden.

bool = true

ruft das Programm "bool" mit den Parametern "=" und "true" auf. Ohne Leerzeichen ist es eine Zuweisung.

nman

tntnet schrieb:

Zu der Diskussion, ob bash irgendwo Standard ist. Ich habe hier fedora und da zeigt /bin/sh auf bash.

Das macht Bash aber nicht zu irgendeiner Art von Standard-sh.

Bash im Shebang anzugeben ist nicht erst seit der Ubuntu-Umstellung wichtig. Die BSDler freuen sich schon seit langer Zeit nicht sehr über Bashismen in Shellskripten, die sh statt bash im Shebang haben.

Bash Newbie: Verwende einstweilen einfach mal #!/usr/bin/env bash als Shebang; das wird idR. auf jedem relevanten System, wo auch eine Bash installiert ist, funktionieren. Wenn keine Bash im Pfad ist, bekommt man eben eine Fehlermeldung, aber das ist ja typischerweise auch das gewünschte Verhalten.

nman

Bash Newbie schrieb:

SeppJ schrieb:
[ … Geflame über ein Bash Tutorial … ]
#!/bin/[b]sh[/b]
Na super.

Kann mir mal jemand sagen, warum Ubuntu die dash als Standardshell verwendet?

Oh, das ist wohl auch ein Missverständnis.

Um das nochmal zu betonen: sh ist nicht einfach _irgendeine_ Standard-Shell. sh ist die Bourne Shell, die zufällig schon lange eine Standard-Shell ist. Die GNU bash verhält sich hinreichend ähnlich wie eine Bourne-Shell, dass viele Distros sh auf bash verlinkt haben, aber wenn du irgendwelche Bash-spezifischen Features verwenden möchtest, musst du auch die Bash in deinen Shebang packen.

tntnet

nman schrieb:

Bash Newbie schrieb:

Kann mir mal jemand sagen, warum Ubuntu die dash als Standardshell verwendet?

Oh, das ist wohl auch ein Missverständnis.

Um das nochmal zu betonen: sh ist nicht einfach _irgendeine_ Standard-Shell. sh ist die Bourne Shell, die zufällig schon lange eine Standard-Shell ist. Die GNU bash verhält sich hinreichend ähnlich wie eine Bourne-Shell, dass viele Distros sh auf bash verlinkt haben, aber wenn du irgendwelche Bash-spezifischen Features verwenden möchtest, musst du auch die Bash in deinen Shebang packen.

Ergänzend sollte erwähnt werden, dass auch die dash sich hinreichend ähnlich zur Bourne-Shell verhält. Daher ist bei einem Bourne-Shell egal, ob /bin/sh auf bash, dash oder sonstwas zeigt.

Dash ist halt kleiner und lädt unter anderem daher schneller als die bash. Und da beim Booten viele (Bourne-)Shell-Skripte ausgeführt werden, hat sich Debian entschlossen, /bin/sh auf /bin/dash zu verlinken. Das verkürzt dann die Bootzeit. Und da Ubuntu auf Debian basiert, findest Du das auch bei Ubuntu.

Ja, ich habe es inzwischen verstanden.

Aber welches Tutorial oder online Buch würdet ihr mir empfehlen um nur die Bourne Shell zu lernen?

CarstenJ

Hi,

ich habe das hier:
Shell-Skript-Programmierung | ISBN: 3826617991

Allerdings eine ältere Version, finde es aber sehr gut.

EDIT: Warum? Weil eben auch auf die unterschiedlichen Shells eingegangen wird und Unterschiede erklärt werden.