ich habe das folgende script: #!/bin/bash -f if [ "$FLIP_HOME" = "" ]; then echo "FLIP_HOME is not defined, please use setenv to set flip home" echo "e.g :" echo "setenv FLIP_HOME /home/flip.3.2.1/bin" exit 1 fi Jetzt kommt immer die Meldung FLIP_HOME is not .... da setenv nicht geht, habe ich export FLIP_HOME=mydirectory gemacht und echo $FLIP_HOME gibt dann auch mydirectory Was is da los? (bin übrigens linux newbie)
setenv gibts bei der bash nicht, da heisst das halt export. Und die bash ist bei Ubuntu AFAIK die Standardshell. Oder wo liegt dein Problem?
Georg A. schrieb: > setenv gibts bei der bash nicht, da heisst das halt export. Und die bash > ist bei Ubuntu AFAIK die Standardshell. Oder wo liegt dein Problem? genau deswegen habe ich ja auch export ..... gemacht. Aber wie oben schon erwähnt kommt immer noch die Meldung FLIP_HOME is not ... obwohl echo $FLIP_HOME wie gewünscht funktioniert!
Funktioniert bei mir ohne Probleme. Wie rufst du nachher dein Shellscript auf? Hoffentlich schon in demselben Konsole-Fenster, in dem du auch den export eingetippt hast? Was passiert wenn du direkt
1 | FLIP_HOME=xxx ./flip.sh |
eintippst? (Eine Zeile!)
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.
Daniel B. schrieb: > Setz mal die Befehl ab (natürlich mit deinen Scriptnamen), so > wie ich es oben gemacht habe, und cut-and-paste den output. wie gesagt, linux ist noch nicht mein Spezialgebiet: Ich hatte zuerst einfach flip.sh versucht, da hat der flip.sh nicht gefunden dann im Internet ein Tip mit sudo flip.sh da hat er das Script zwar gestartet aber wie beschrieben die Variable nicht mehr gekannt jetzt mit ./flip.sh geht es Klaus Wachtler schrieb: > 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? nein, anders: ich möchte in der shell (bash) die Variable setzen und im Script, dass ich dann aufrufe, soll sie bekannt sein > 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.:. ./meintollesskript ja, wie schon gesagt, damit geht es (aber warum) Danke an alle und die Frage nach einer umfassenden Einführung zu Linux im Internet (nicht irgendwelche Befehlserklärungen sondern mehr das Grundlegende) damit ich auch ohne eure Hilfe weiterkomme ... (bitte kein Hinweis auf google)
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.
Daniel B. schrieb: > 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. den Teil von Linux hab ich dank deiner guten Erklärung jetzt verstanden, ich suche aber noch nach einer guten Einführung in die Grundlagen von Linux im Internet in der z.B. auch steht was es mit .bashrc etc. auf sich hat weiß da jemand was empfehlenswertes?
Wenn du Englisch kannst, lies die manpage zur bash (evtl. gibts die auch auf Deutsch...). Ist zwar umfangreich, aber wichtig ist eigentlich, dass man mal "gelesen" hat, was die alles kann. Im Bedarfsfall kann man ja dann nochmal genau nachschauen. Suchen kann man mit /begriff (und n für die weiteren Corkommen) auch, damit bekommt man auch zB. zum Thema bashrc alles gesagt. Ausschnitt: " When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist."
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
Eine große Übersicht über viele Funktionen und Tipps zur Bash findest du auf Wikibooks: http://de.wikibooks.org/w/index.php?title=Spezial%3ASuche&search=bash Und wichtig: Benutze sudo wirklich nur, wenn du es wirklich brauchst! sudo führt den Befehl/das Script/usw. als root aus und kann somit das System zerstören. In fast allen Fällen ist das aber nicht nötig. Eigene Scripte startest du entweder mit dem absoluten Pfad (ausgehend vom Root-Verzeichnis / ): /home/benutzer/scripte/abc.sh oder wenn du schon im Verzeichnis bist mit: ./abc.sh (Nur Beispielnamen) ./abc.sh bedeutet: such im aktuellen Verzeichnis (dafür steht der .) nach dem Script abc.sh und starte es. Füge außerdem nicht wie oben vorgeschlagen . zum PATH hinzu. Es hat gute Gründe warum das da nicht schon von alleine drin steht.
Georg A. schrieb: > setenv gibts bei der bash nicht, da heisst das halt export. Und die bash > ist bei Ubuntu AFAIK die Standardshell. Oder wo liegt dein Problem? Ne, Standard ist schon seit mehreren Versionen "dash"
> 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.
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...
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.