Karl Sinn

Scheinbar muss zwischen "Hallo" und ] ein Leerzeichen stehen. Ich habs reingemacht, und jetzt gehts auch mit dem if.

jau das ist so. Grund [ .. ] ist keine Bash-Syntax, sondern [ ist für (manche) andere Bourne- Shells (also Solaris oder so) ein symbolic link auf /bin/test. Deshalb ist ] ein Argument für /bin/test und wird von test erwartet, wenn man es als [ aufruft. Steht nun kein Space nach "Hallo" vor dem ] dann fehlt eben ein Argument.

Eine weitere Frage:

In dem Tutorial steht, dass [ ] für alte bashs ist und (( )) für neuere Versionen.

Nun ja: wenn das Ziel ist portable shell-Script zu schreiben (also solche die auch mit der Shell von AIX oder Solaris laufen), dann verbieten sich solche BASH-Sachen. Ansonsten glaube ich betrachtet die bash [ als "builtin" Kommando. ((..)) kann aber noch mehr als das einfache [ .. ] So long Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 9204871 Fax: +49(721) 24874 Juergen.Vollmer@[informatik-vollmer.de|alumni.uni-karlsruhe.de|acm.org] www.informatik-vollmer.de

* Karl Sinn:

1) Ich habe gerade gemerkt, dass bei der Übergabe von Parametern wie z.B * nicht "*" übergeben wird sondern alle passenden Dateien als Parameter.

'*' oder \* statt * als Parameter benutzen.

2) Warum funktioniert das jetzt nicht?

Was soll es denn machen?

testen=$1 while [ $testen -ne "" ] do echo "Dateinamen: ab $1$2" shift testen=$1 done

Zuerst mal ein Semikolon vor do. Thorsten -- You talkin' to me? Get my public GPG key: 0xF99C905C

Hallo, Am Mon, 08 Dec 2003, Karl Sinn schrieb:

Noch ein paar Fragen:

1) Ich habe gerade gemerkt, dass bei der Übergabe von Parametern wie z.B * nicht "*" übergeben wird sondern alle passenden Dateien als Parameter. Kann man das umgehen?

Du musst den '*' quoten, sonst expandiert den die shell. Alles weitere ist dann nur die logische Folge. Vgl. z.B. 'find . -name "*.foo"'.

2) Warum funktioniert das jetzt nicht?

testen=$1 while [ $testen -ne "" ] do ^^ Du willst dringend 'help while' lesen!

while: while COMMANDS; do COMMANDS; done ^!! while test "$testen" != ""; do ... Siehe dazu 'help test' unter besonderer Beachtung von String vs. Integervergleich. Uebrigens: es ist _wichtig_, dass du die zu vergleichende Variable quotest, sonst faellst du auf die Schnauze, wenn diese leer ist. Robust ist folgendes: while test "x${testen}" != "x"; do ... done alternativ evtl.: while test -n "$testen"; do ... done und wie gesagt: immer schoen brav quoten! Sonst bekommst du sehr schwer nachvollziehbare Fehler!

echo "Dateinamen: ab $1$2" shift testen=$1 done

Was willst du damit machen?

bash-Programmierung ist ganz schön undurchschaubar

Nicht, wenn man da systematisch rangeht. -dnh PS: Karl, mach dir bitte mal die Muehe und lese dir mal ein paar Grundlagen an und lerne diese, indem du jedes "Konstrukt" austestest. Im Archiv findest du da einige Texte zu, oder auch auf selflinux.de und anderswo. -- ...on the mis-spelling of "deity" as "diety": 'I before E except when referring to your god.' 'There are no Is or Es (though plenty of "Aieee!"s) in "Cthulhu".' -- Axly and Mark in the SDM

Hallo, * Bernd Obermayr textete am 08.12.03:

David Haller schrieb:

Was mir bei dem Thread wieder stark auffällt: Was ist mit Bernd Brodesser? "Ewig" schon nix mehr von ihm gelesen =8-(

Also das was ich in suse-talk gelesen habe, hat der sich für eine Weile verabschiedet, wohl wegen Freundin/Zeit usw. Und wenn ich's nicht ganz falsch verstanden habe, will er in diesem Monat wieder auftauchen. cu flo -- Wenn man aber schon betriebsblind User nur noch provoziert, muss man sich nicht wundern, wenn es ewig dauert, bis sie eurer Hinweise als glaubhaft lesen werden. [Frank Toennes in dag°]

Hallo, Am Mon, 08 Dec 2003, Karl Sinn schrieb:

David Haller schrieb:

...

Du willst dringend 'help while' lesen!

while: while COMMANDS; do COMMANDS; done ^!!

while test "$testen" != ""; do ... PS: Karl, mach dir bitte mal die Muehe und lese dir mal ein paar Grundlagen an und lerne diese, indem du jedes "Konstrukt" austestest. Im Archiv findest du da einige Texte zu, oder auch auf selflinux.de und anderswo.

JA, ICH WILL, ICH WILL, ICH WILL lol

*g*

Das ist ja gerade das was mich so nervös macht :-) Den ganzen Morgen habe ich rumgelesen, und noch nicht einmal ein einfaches if then fi hinbekommen. Ich habe übrigens in der Linuxfibel gelesen, und da habe ich folgenden Text gefunden (O-Ton: http://www.linuxfibel.de/bash.htm):

...

if Liste von Kommandos; then Liste von Kommandos [elif Liste von Kommandos; then Liste von Kommandos] [else Liste von Kommandos] fi

Und mit Liste von Kommandos, konnte ich so einfach nichts anfangen.

Siehe Abschnitt "Listen" im o.g. Dokument. Damit ist einfach ein oder mehrere Kommandos, die auch verknuepft sein koennen. if wertet dann nur den Exitstatus der gesamten Kette aus: if true; then echo "TRUE"; else echo "FALSE"; fi ^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^^ das sind die "Liste von Befehlen". if true; false; then echo "TRUE"; else echo "FALSE"; fi if true; false; true; then echo "TRUE"; else echo "FALSE"; fi if false; false; true; then echo "TRUE"; else echo "FALSE"; fi if false; false; false; then echo "TRUE"; else echo "FALSE"; fi Hier ist jew. der "Exitcode" der "Liste von Befehlen" (in der Bedingung) jeweils _nur_ der Exitcode des letzten Befehls. if true && false; then echo "TRUE"; else echo "FALSE"; fi if true && false || true; then echo "TRUE"; else echo "FALSE"; fi Statt dem 'echo ""' kann jeweils auch eine bel. Anzahl Befehle stehen, z.B.: then echo "TRUE" grep foo /tmp/bar sleep 2 echo "Huhuu" else ... fi Hier ist alles zwischen "then" und "else" eine "Liste von Befehlen".

Zumal als Beispiel dann direkt sowas folgt:

...

if test $( id | awk -F'[=(]' '{print $2}'; ) -eq "0"; then echo Superuser; else echo Normaler User; fi

Dass das test darin so wichtig ist, habe ich nicht kapiert.

Ist es auch nicht :) Nur fuer das was gemacht werden soll. Schau dir mal an, zu was $() expandiert: id gibt u.a. als erstes die UID aus, in der Form 'uid=$UID(username)...'. Das awk popelt daraus dann die numerische UID heraus, z.B. 500 oder 0. Das ganze $() Konstrukt expandiert also zur UID des users. Was macht nun das test? user$ test $(...) -eq 0 expandiert z.B. zu: test 500 -eq 0 root# test $(...) -eq 0 expandiert zu: test 0 -eq 0 Wie du in 'help test' nachlesen kannst vergleicht test mit -eq Zahlen auf numerische Gleichheit und gibt bei Gleichheit 0 ("true"), bei Ungleichheit 1 ("false") als Exitstatus zurueck. Und dieser ist dann die Bedinung des 'if'. Das Beispiel ist uebrigens schlampig, denn es wird ein String als Vergleich angegeben.

Weiter unten:

...

while Bedingung do Liste von Kommandos done

until Bedingung do Liste von Kommandos done

Da steht kein Semikolon.

Das ist falsch bzw. ein "Bug" im Dokument. Da muss ein Zeilenumbruch oder ein Semikolon hin. while Liste von Befehlen do Liste von Befehlen done oder while Liste von Befehlen; do Liste von Befehlen; done Das sind einfach die generellen Regeln bzgl. Trennung von Kommandos in der bash.

Und mit Bedingung

Die Schleife wird solange ausgefuehrt, bis die "Liste von Befehlen" einen Exitstatus ungleich 0 zurueckgibt. i=0; while test $i -lt 5; do echo "$i"; i=$(( i + 1 )); done while false; do echo "wirste nicht sehen!"; done

...

Was willst du damit machen?

Die grundidee war etwas über Bashprogrammierung zu lernen. Die mir gestellte Aufgabe ist ein Script, dass alle Ihm übergebenen Dateien nach einem Muster durchnummeriert (fürs Photoalbum)

Ahso. Da bieten sich for `seq ... ` oder eine while-Schleife wie oben mit $i an, sowie printf um den Dateinamen zu formatieren, z.B.: i=1 ls *.jpg | while read dateiname do neuername="`printf 'Bild%06i' $i`" ### siehe 'man 1 printf' echo mv -i "$dateiname" "$neuername" i=$(( i + 1 )) done [das mv durch das echo entschaerft]

Jetzt werde ich erst mal alles was Ihr alle vorgeschlagen habt in Ruhe lesen, und testen, in meiner Linuxfibel weiterlesen, und dann mit Sicherheit wieder eine Frage stellen;

Kennst du den Text von Kristian? Und den von selflinux? http://www.koehntopp.de/kris/artikel/unix/shellprogrammierung/ http://www.selflinux.org/selflinux/html/shellprogrammierung.html -dnh -- Any research done on how to efficiently use computers has been long lost in the mad rush to upgrade systems to do things that aren't needed by people who don't understand what they are really supposed to do with them. -- Graham Reed

Hallo, Am Mon, 08 Dec 2003, Karl Sinn schrieb:

UPS...

Karl Sinn schrieb:

...

# Umbenennen / Nummerieren aller Dateien if [ "$1" = "Hallo"] ; then echo "Benutzung: ./rename Dateien Datei-Prefix ErsteNummer" fi

Scheinbar muss zwischen "Hallo" und ] ein Leerzeichen stehen. Ich habs reingemacht, und jetzt gehts auch mit dem if.

Ja. Du solltest 'help test' und 'man test' lesen.

Eine weitere Frage:

In dem Tutorial steht, dass [ ] für alte bashs ist und (( )) für neuere Versionen.

Was benutzt man am besten?

Weder noch. Man sollte if test "$1" = "$Hallo"; then ... fi verwenden. 'if [ ... ]' ist _keine_ shell-syntax, das ist ein builtin- oder ein externer Befehl namens "test"... Ausserdem macht einem die Verwendung von 'test' klarer, was eigentlich ablaeuft, naemlich, dass 'if' schlicht den Exitstatus eines Befehlst testet. Also auch z.B. bei 'if grep -q foo ~/bar' eben den von grep. -dnh -- I think that all good, right thinking people in this country are sick and tired of being told that all good, right thinking people in this country are fed up with being told that all good, right thinking people in this country are fed up with being sick and tired. I'm certainly not, and I'm sick and tired of being told that I am. -- Monty Python

On Mon, 2003-12-08 at 14:47, Thomas Vollmer wrote:

On Monday 08 December 2003 14:07, Karl Sinn wrote:

...

Hallo,

jetzt lese ich schon seit Strunden im Bash-Tutorial von http://www.linuxfibel.de/bash.htm und bekomme es einfach nicht hin:

Wir prüfe ich den Übergabeparameter $1 auf einen bestimmten Wert?

if $1 == "Hallo"; then echo $1 fi

Da fehlt das test (bzw. kurzform [ ). Und test kennt kein ==, sondern für Zeicheketten das =. Siehe `man test'. Nun ja, die Bash kennt sehr wohl "==", andere Shells allerdings nicht, weshalb man '==' möglichst schnell wieder vergessen sollte.

So gesehen, hat die Manpage und 'help test' schon recht, '==' nicht zu dokumentieren. Ralf