Kubuntu: Variable setzen geht nicht?!

Versuchs mal mit:

if [ "$FLIP_HOME" == "" ]; then

Deine Version ist eine Zuweisung, nicht ein Vergleich.
Passiert einem Anfänger häufig bei einer IF-Abfrage ;-)

Daniel

Daniel B. schrieb:
> Versuchs mal mit:
>
> if [ "$FLIP_HOME" == "" ]; then
>
> Deine Version ist eine Zuweisung, nicht ein Vergleich.
> Passiert einem Anfänger häufig bei einer IF-Abfrage ;-)
>
> Daniel

In der bash ist = be nem Test der Stringvergleich.
Siehe man test.

Aber macht nix, passiert einem Anfänger öfter :-)

@ Benny:

Ich habe noch nicht ganz verstanden, was du vorhast.
Vermutung: du bist in einer Shell (Terminal oder was
auch immer), möchtest das obige Skript starten und hoffst
dann nach Beenden des Skripts, in deiner wieder aktuellen Shell
die Environment-Variable geändert zu haben?
Diese Hoffnung wäre vergebens, weil ein Prozeß nicht bei seinem
Vater oder anderen Vorfahren das Environment ändern kann, nur
für seine zukünftigen eigenen Kinder.

Falls meine Vermutung stimmt, musst du dein obiges Skript
aufrufen mit einem vorangestellten Punkt und Leerzeichen, also z.B.:

1

. ./meintollesskript

Dadurch läuft das Skript nicht in einer neuen Shell, sondern in
der aktuellen und kann dort die Variable ändern.
Dann kannst du in dein Skript eine Zeile einbauen in der Art:

1

#!/bin/bash -f

2

if [ "$FLIP_HOME" = "" ]; then

3

  echo "FLIP_HOME ist nicht gesetzt, ich setze es mal auf blabla"

4

  export FLIP_HOME="blabla"

5

fi

hehe, kleines Eigentor. Habe mich so an die alte Notation gewöhnt.
Und von C und Perl her, habe ich eine Abneigung gegen solche If's

Bei mir läuft auf jeden Fall das Script, so wie es soll:

1

su23sr4:~: ps

2

   PID TTY         TIME CMD

3

 12136 pts/1       0:00 ps

4

  4007 pts/1       0:00 bash

5

6

su23sr4:~: ls -l xx.sh

7

-rwxr-xr-x   1 daenu  crappl       192 Dec 14 13:48 xx.sh

8

9

su23sr4:~: cat xx.sh

10

#!/bin/bash -f

11

if [ "$FLIP_HOME" == "" ]; then

12

  echo "FLIP_HOME is not defined, please use setenv to set flip home"

13

  echo "e.g :"

14

  echo "setenv FLIP_HOME /home/flip.3.2.1/bin"

15

  exit 1

16

fi

17

18

su23sr4:~: echo $FLIP_HOME

19

mydirectory

20

su23sr4:~: ./xx.sh

21

su23sr4:~: export FLIP_HOME=""

22

su23sr4:~: ./xx.sh

23

FLIP_HOME is not defined, please use setenv to set flip home

24

e.g :

25

setenv FLIP_HOME /home/flip.3.2.1/bin

@Benny: Setz mal die Befehl ab (natürlich mit deinen Scriptnamen), so
wie ich es oben gemacht habe, und cut-and-paste den output.

Aufgerufene Kommandos werden unter Linux folgendermaßen gesucht
(vereinfacht):
1. Falls es ein internes Kommando der Shell ist, dann wird es
   als solches ausgeführt (test, export, ...)
2. Dann wird die Liste der alias-Definitionen abgeklappert, ob es
   dabei ist.
(Kann auch sein, daß 1. und 2. vertauscht werden, müsste ich nachsehen.)
3. Es werden alle Pfade in der Variablen PATH hergenommen und
   nachgesehen,. ob es dort eine ausführbare Datei mit dem
   Kommandonamen gibt. Falls ja, dann wird diese Datei ausgeführt
   (wie gesagt für ein Shellskript in einer eigenen Shell).

Üblicherweise ist . nicht in PATH, deshalb wird ein Kommando
nicht gesucht im aktuellen Verzeichnis.

Ok, jetzt ist alles klar, deine Shell findet dein Script nicht, da in
deiner PATH Variable der Eintrag fehlt, in deinem aktuellen Pfad
nach zu schauen.

Bei mir sieht die in etwa so aus:

su23sr4:~: echo $PATH
/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/site/bin:/usr/sfw/bin:/usr/ 
local/rrdtool/bin:/opt/gcc/bin

Wenn ich jetzt mein Script ohne ./ am Anfang aufrufe, passiert 
folgendes:

su23sr4:~: xx.sh
-bash: xx.sh: command not found

Mit "type" findest Du raus, was die Shell starten würde, wenn Du etwas
eingibst:

su23sr4:~: type xx.sh
-bash: type: xx.sh: not found

Wenn Du nun folgendes machst:

su23sr4:~: export PATH=$PATH:.
su23sr4:~: echo $PATH
/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/site/bin:/usr/sfw/bin:/usr/ 
local/rrdtool/bin:/opt/gcc/bin:.

man beachte den :. am Schluss.

Dann weisst Du die Shell an, auch im aktuellen Pfad zu suchen, und nun 
findet sie dein Script auch:

su23sr4:~: type xx.sh
xx.sh is ./xx.sh

Ob nun der aktuelle Pfad in der PATH Variable sein soll, darüber wird
seit jeher in der UNIX-Welt gestritten. Sicher ist, dass das beim
Superuser "root" das auf keinen Fall sein sollte, da man ihm sonst
irgend welche Scripts unterjubeln kann.

Mit "sudo" hast Du deine Identität auf den User "root" gewechselt.
Damit wurde auch eine völlig neue Shell gestartet, OHNE das die
aktuellen Variablen mitgenommen wurden.

Also entweder erweiterst Du deine PATH Variable zum Beispiel im
.bashrc in deinem HOME-Directory mit einem ":." oder Du startest deine
Scripts immer mit dem absoluten oder relativen Pfad vorne dran.

Ein wirlich guter Link weiss ich auch gerade nicht. Ev: 
http://stefaanlippens.net/bashrc_and_others

Ist auch ein bisschen schwierig, da sich in diesem Bereich die einzelnen 
Unix-Derivate unterscheiden.

Im Normalfall werden bei einem Login die folgenden Files ausgeführt:
- /etc/profile
- $HOME/.profile
- /etc/bash/bashrc oder ähnlich (wenn vorhanden)
- /etc/bash_bashrc (wenn vorhanden)
- $HOME/.bashrc (wenn vorhanden)
- $HOME/.bash_profile (wenn vorhanden)
- $HOME/.bash_login (wenn vorhanden)

Um rauszufinden, wie es auf einem neuen System funktioniert, mache ich 
meistens folgendes. Ich suche alle Files im /etc Verzeichnis, die 
"profile" oder "bash" im Namen haben und das gleiche in meinem 
Homeverzeichnis.
In jedes dieser Files trage ich eine Zeile wie diese ein:

echo "Ich bin das .profile"

Natürlich entsprechend dem aktuellen File, so dass ich sie unterscheiden 
kann. Wenn ich mich dann einlogge, oder ein neues Terminalfenster 
öffene, sehe ich, welche Files durchlaufen werden. Bei mir passiert 
folgendes:

Ich bin das /etc/profile
Ich bin das HOME/.profile
Ich bin das HOME/.bashrc

Also einfach mal ausprobieren, kaputt gehen kann nichts ;-)

Daniel

Georg A. schrieb:
>> Ne, Standard ist schon seit mehreren Versionen "dash"
>
> Ja, stimmt. Das Sch...-Teil habe ich verdrängt. Die kann leider mit
> einigen Bash-Konstrukten nichts anfangen, was insb. wegen dem Link
> /bin/sh nach /bin/dash diverse Standard-Shellskripte erstmal mit völlig
> unverständlichen Fehlermeldungen terminiert.

Wenn das Skript am Anfang ein "#!/bin/sh" angibt, dann darf es eben 
nicht davon ausgehen, daß es von einer bash ausgeführt wird muß und sich 
auf die in POSIX definierten Shell-Features beschränken. Wenn es 
bash-spezifische Konstrukte enthält, dann doch bitte explizit 
"#!/bin/bash" angeben. Es ist nicht die Schuld der dash, wenn in 
Skripten der falsche Interpreter angegeben ist.

> Und das alles nur, weil die Jungs 700K sparen wollen. Auf einem
> Desktop/Server. Zu Zeiten, wo einem die TB-Platten um die Ohren gehauen
> werden. Und wo allein schon "vim-tiny" über 600KB hat. Völlig hirnrissig
> das ganze...

Es geht nicht um das Sparen von 700k, sondern darum, daß die bash extrem 
mächtig, aber auch sehr träge ist. Die dash ist dafür ausgelegt, nicht 
viel mehr als das zu implementieren, was von POSIX verlangt wird und 
dadurch  schlank und schnell zu sein. Die dash ist beim Ausführen von 
Skripten deutlich schneller als die bash. Da nach den Debian-Regeln die 
ganzen Systemskripte eh nur POSIX verwenden sollen, müssen sie 
eigentlich auch mit der dash gehen, sonst ist das ein Fehler im Skript.
Übrigens steht das 'd' für debian. Die dash ist also nicht etwa auf dem 
Mist von Ubuntu gewachsen, sondern eine debian-Erfindung. Nur hat sich 
Ubuntu halt als erster getraut, sie auch konsequent einzusetzen.