ole@defiant:~/skripte> source ./werist ole
Die Angabe ./werist sagt, daß die Datei in dem aktuellen Arbeitsverzeichnis ist. Um dies zu umgehen, können Sie das aktuelle Verzeichnis, dargestellt durch den Punkt ``.'', in den Pfad einfügen.
ole@defiant:~/skripte> echo $PATH /usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin: /opt/kde2/bin:/usr/lib/java/bin:/opt/gnome/bin:.
Achten Sie bitte darauf, daß das aktuelle Verzeichnis am Ende der Liste steht. Für den Systemadministrator root tragen Sie bitte nie das aktuelle Verzeichnis in den Pfad ein.
Es gibt auch eine kürzere Variante um ein Skript zu starten. Verwenden Sie einfach anstatt von source den Punkt.
ole@defiant:~/skripte> . ./werist ole
Sie können das Skript auch starten, indem Sie eine neue Instanz der Bash aufrufen.
ole@defiant:~/skripte> /bin/bash ./werist ole
Diese Methode verhält sich aber anders als die vorher vorgestellten Methoden. Es wird explizit eine neue Shell gestartet, in der dann das Skript ausgeführt wird. Das hat natürlich zur Folge, daß Variablen, die nicht exportiert worden sind, in dieser Shell nicht zur Verfügung stehen.
Sie kommen aber auch ohne einen zusätzlichen Befehl aus. Machen Sie einfach aus der normalen Textdatei eine ausführbare Datei. Unter Linux ist alles ausführbar, wenn es einen Inhalt besitzt, der durch den Prozessor (nativer Code) oder durch ein anderes Programm (interpretierter Code), wie z. B. die Shell, ausgeführt werden kann.
Um eine Datei ausführbar zu machen, müssen Sie das X-Recht setzen.
ole@defiant:~/skripte> ls -l werist -rw-r--r-- 1 ole users 114 Nov 20 12:48 werist ole@defiant:~/skripte> chmod a+x werist ole@defiant:~/skripte> ls -l werist -rwxr-xr-x 1 ole users 114 Nov 20 12:48 werist
Jetzt können alle (Besitzer, Gruppe und der Rest der Welt) dieses Skript ausführen, indem Sie einfach den Namen eingeben.
ole@defiant:~/skripte> werist ole Login: ole Name: Ole Vanhoefer Directory: /home/ole Shell: /bin/bash On since Wed Nov 20 10:03 (CET) on :0, idle 200 days 20:28, from console On since Wed Nov 20 10:04 (CET) on pts/0, idle 5:09 On since Wed Nov 20 10:14 (CET) on pts/1 (messages off) On since Wed Nov 20 10:53 (CET) on pts/2, idle 2:38 (messages off) On since Wed Nov 20 12:45 (CET) on pts/3, idle 2:19 (messages off) New mail received Thu Oct 10 11:20 2002 (CEST) Unread since Mon Jul 15 21:28 2002 (CEST) No Plan. root 2049 0.0 1.4 3408 1776 ? S 10:03 0:00 /usr/X11R6/bin/xconsole -notify ole 2058 0.0 0.0 2560 0 ? SW 10:03 0:00 /bin/sh /usr/X11R6/bin/kde ole 2106 0.0 0.7 19560 924 ? S 10:03 0:00 kdeinit: Running... ole 2109 0.0 1.2 19544 1544 ? S 10:03 0:00 kdeinit: dcopserver --nosid ole 2112 0.0 2.2 21824 2788 ? S 10:03 0:00 kdeinit: klauncher ...
Es ist ohne Frage von Vorteil, wenn das Skript selber die Information enthalten würde, durch welchen Interpreter die enthaltenen Kommandos ausgeführt werden sollen. In der Bash ist dies durch die Zeichen ``#!'' realisiert, die am Anfang der ersten Zeile stehen. Diese Konstruktion wird umgangssprachlich She-Bang genannt. Diese Wortschöpfung setzt sich aus den Bezeichnungen sheepgate für das Doppelkreuz `#' und bang für das Ausrufungszeichen zusammen.
So beginnt ein Skript, daß für die Bash geschrieben wurde, mit der folgenden Zeile.
#!/bin/bash
Die Bash untersucht die erste Zeile des Skripts, startet den gefundenen Interpreter und übergibt das Skript an diesen Interpreter zur Ausführung.
|
Ein falsche She-Bang-Anweisung ist ein häufiger Grund für eine fehlerhafte Ausführung des Skripts. In diesem Fall meldet die Bash und nicht der Interpreter einen Fehler.
In dem im folgenden Beispiel gestarteten Skript wurde ein falscher Interpreter eingetragen. Die Fehlermeldung kommt von der Bash.
ole@enterprise:~/test> shebang bash: ./shebang: bad interpreter: Datei oder Verzeichnis nicht gefunden
Eine grundlegende Unix-Regel besagt, daß Kinder-Prozesse die Variablen von Ihrem Eltern-Prozeß erben. Die Variablen des Kinder-Prozeß sind aber nur während seiner Ausführung gültig und werden nicht zur Eltern-Shell zurückgegeben. Also haben Variablenänderungen in diesem Prozeß keine Auswirkungen auf die Variablen im Eltern-Prozeß.
Dies Verhalten läßt sich am folgenden Beispiel nachvollziehen.
ole@enterprise:~/test> cat shebang #!/bin/bash echo $var var="Neuer Wert" echo $var ole@enterprise:~/test> var="Alt" ole@enterprise:~/test> export var ole@enterprise:~/test> shebang Alt Neuer Wert ole@enterprise:~/test> echo $var Alt