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

Ich habe hier eine Schleife die endlos wiederholt wird, es sei denn, die Variable $bool die in while als Bedingung drinsteht wird auf false gesetzt.

Das Problem an dem Code ist jetzt nur, dass er nicht funktioniert.

#!/bin/sh

set $bool = true 
while $bool ; do
  echo
  $bool = false
done

echo "mach weiteres..."

Ich habe schon auf andere Weise versucht die Variable zu ändern.

z.B. mit den Anweisungen:

$bool := false$ bool =: false
set $bool = false

aber keine von denen hat funktioniert.
Lediglich die letzte mit set meldete keine Fehler, aber die Schleife wurde dennoch endlos weiter ausgeführt.

Alternativ dazu suche ich eine andere Möglichkeit eine endlose While Schleife zu verlassen.
Mit exit geht das zwar auch, aber dann wird das ganze Script verlassen, was ich nicht möchte, denn am Ende soll nach der Schleife noch etwas weiteres gemacht werden.

Shade Of Mine

Wie waere es, wenn du einfach ein Tutorial liest?

zB das hier: gutes Bash Tutorial

Shade Of Mine schrieb:

Wie waere es, wenn du einfach ein Tutorial liest?

zB das hier: gutes Bash Tutorial

Weil in einem Tutorial keiner schreibt, wie man eine Variable wieder ändert.

Beispiel:

http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-5.html

This example should be enought to show how to use a local variable.

Guckt man sich diese Seite an und beachtet man nochmal, was ich erreichen will, dann reicht dieses Beispiel nicht.

Außerdem lernt man durch praktisches probieren besser und schneller als durch Tutorials die um den Brei herumreden.

Und schließlich habe ich schon einmal ein Tutorial vor Jahren durchgearbeitet.
Wie man ne while Schleife macht, weiß ich also, aber die Detauls und was davon hängen blieb, sieht man ja.
Tutorials bringen nichts, wenn man keine praktischen Erfahrungen sammelt.

Und letzteres versuche ich gerade.

Okay, ich bin nun etwas weiter.

Aber warum ist bool in der if Bedingung wahr?

#!/bin/sh

bool=true 
echo $bool
bool=false
echo $bool

# Bis hierhin geht es.
# bool ist ab hier nun false

# Aber das geht nicht mehr

if [ $bool ]; then
  echo "bool ist wahr"
else
  echo "bool ist false"
fi

# Wieso ist bool wahr, wenn es false sein müßte?

bool=true
while $bool ; do
  echo $bool
  # Schleife dürfte nur ein einziges mal durchlaufen werden.
  bool=false
done

echo "Super!"

Shade Of Mine

Bash Newbie schrieb:

Weil in einem Tutorial keiner schreibt, wie man eine Variable wieder ändert.

Der 1. Hit von der mir verlinkten Google Suche beantwortet deine Frage.

Es macht keinen Sinn hier mit dir ueber sowas zu reden. Lies ein gutes Tutorial, besser noch ein Buch und komm wieder wenn du eine konkrete Frage hast.

Gerade zu bash gibt es unendlich viele Resourcen.

Shade Of Mine schrieb:

komm wieder wenn du eine konkrete Frage hast.

Wie schon gesagt, ich habe schon ein Tutorial gelesen und was meinst du was ich in den letzten 50 Minuten schon wieder gemacht habe.

Und ich habe ne konkrete Frage, schau dir den letzten Beispielcode an und sag mir, warum die If Bedingung hier von WAHR ausgeht?

Und ich habe sogar noch eine weitere konkrete frage.

Dieser Befehl funktioniert im Terminal fehlerfrei und hebt den Text farbig hervor

echo -e "\033[0;31mLanger Test...\033[0m"

Aber sobald ich das genau so wie es ist, in ein Script einbaue, wird mir jedesmal -e mit ausgegeben, wenn das Script gestartet wird.

Wieso ist das so?
-e müßte doch eine Parameter für echo sein.

Und warum ist der Eintrag in diesem Buch falsch:
http://linuxint.com/DOCS/Linux_Docs/openbook_shell/shell_008_000.htm

Probiert man 6.1 und 6.1.1. aus, dann geht nur 6.1 und das obwohl ich hier die Bash Shell, wie von 6.1.1 verlangt wird, habe:

#!/bin/sh

# geht
print_error1() {
  echo -e "\033[0;31m$bool\033[0m"
}

# geht nicht
function print_error2 {
  echo -e "\033[0;31m$bool\033[0m"
}

bool=wahr

print_error1
print_error2

6.1.1 liefert den Fehlercode:

./endlos.sh: 11: Syntax error: "}" unexpected

Bash Newbie schrieb:

Und warum ist der Eintrag in diesem Buch falsch:
http://linuxint.com/DOCS/Linux_Docs/openbook_shell/shell_008_000.htm

Probiert man 6.1 und 6.1.1. aus, dann geht nur 6.1 und das obwohl ich hier die Bash Shell, wie von 6.1.1 verlangt wird, habe:
#!/bin/sh

# geht
print_error1() {
  echo -e "\033[0;31m$bool\033[0m"
}
 
# geht nicht
function print_error2 {
  echo -e "\033[0;31m$bool\033[0m"
}

bool=wahr

print_error1
print_error2
6.1.1 liefert den Fehlercode:
./endlos.sh: 11: Syntax error: "}" unexpected

Und übrigens, schreibt man noch () hinter

function print_error2() {

dazu, dann lautet die Fehlermeldung so:

./endlos.sh: 9: Syntax error: "(" unexpected

Das einzige was funktioniert ist die klassische Funktionsanweisung ohne function als Schlüsselwort und mit ().

blafunc() {
}

Das tolle Tutorial bzw. Buch behauptet völlig Falsches.

SeppJ

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

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.