Über die Verwendung von ./ in Shell-Befehlen

Die Zeichenkombination ./ — also ein Punkt gefolgt von einem Schrägstich (auch bekannt als Slash) — wird oft vor Linux-Befehle gestellt. Besonders Linux-Einsteiger stolpern über diese Kombination, wenn es darum geht ein Programm oder ein Skript auszuführen, das im aktuellen Verzeichnis einer Shell liegt. Was steckt hinter diesem kryptischen Kommando und muss man es immer eingeben? Ich versuche den Dschungel etwas zu lüften.

Bevor ich zum ./ komme muss ich etwas ausholen und ein paar Grundlagen in Bezug auf die Linux-Shell und die Umgebungsvariable $PATH verlieren. Eine Shell ist ein Programm, das eine textbasierte Benutzerschnittstelle zur Verfügung stellt, in die der Benutzer Befehle eingeben kann, die dann letztendlich von der Shell ausgeführt werden.

Bei der Ausführung eines Befehls in Linux-Systemen wird immer entweder ein in der Shell fest eingebautes Kommando ausgeführt oder ein ausführbares Programm oder Skript, das sich irgendwo auf der Festplatte befindet. Zur ersten Gruppe gehören Befehle wie cd, ls, echo, kill oder alias. Diese Befehle sind fest in der Shell eingebaut, es gibt also nirgends ein Programm, das beim Aufruf dieser Befehle ausgeführt wird. Im Gegensatz dazu stehen ausführbare Programme wie mv, less, gedit oder gar firefox deren ausführbare Programmdateien oft im Verzeichnis /usr/bin stecken.

Gibt man nun einen Befehl in eine Shell ein, so überprüft die Shell erst einmal ob dieser Befehl eingebaut ist. Erkennt die Shell einen externen Befehl, so durchsucht die Shell den Pfad (über die Variable $PATH) nach einer ausführbaren Datei mit dem selben Namen und führt die Datei aus, wenn die Suche erfolgreich war. Über…

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

…könnt Ihr euch den aktuellen Suchpfad anzeigen lassen. In jedem dieser Verzeichnisse sucht die Shell nach ausführbaren Dateien. Die Reihenfolge der Einträge ist dabei von Relevanz. Wird nach foo gesucht und in /usr/local/bin das Skript gefunden, dann wird /usr/local/bin/foo ausgeführt, auch wenn es in /usr/bin auch noch eine Datei namens foo gäbe. Diesen Punkt darf man nicht aus dem Gedächtnis verlieren.

Skripte in einem Verzeichnis ausführen

Nun kann ich den Bogen zum ./ langsam wieder schließen. Ihr wollt ein Skript oder ein Programm ausführen. Als Beispiel wähle ich ein Skript namens beispiel.sh im Verzeichnis ~/tmp in eurem Homeverzeichnis. Dazu öffnet ihr ein Terminal, gehe in das Verzeichnis in das sich das Skript befindet und versuche es aufzurufen…

otto@computer:~$ cd tmp
otto@computer:~/tmp$ beispiel.sh
beispiel.sh: command not found
otto@computer:~/tmp$ ls -al beispiel.sh
-rwxr-xr-x 1 otto otto 61 2010-02-03 15:28 beispiel.sh

Wie Ihr seht wird das Skript nicht gefunden und das obwohl ich mich im passenden Verzeichnis befinde. Das Skript da ist und die Rechte auch stimmen. Warum klappt das also nicht? Die Lösung liegt im vorhin beschriebenen $PATH. Zur Erinnerung gebe ich ihn nochmal aus…

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Die Shell erkennt schnell, dass das Kommando beispiel.sh kein eingebautes Shell-Kommando ist, daher wird im zweiten Schritt der Pfad durchsucht. Auch hier kommt die Shell wieder zu keinem positiven Ereignis. In allen Verzeichnissen, die im $PATH enthalten sind, wird keine Datei beispiel.sh gefunden, daher wird „command not found“ ausgegeben. Was ist da also los? Der Grund ist einfach: Der $PATH enthält nie das aktuelle Verzeichnis in dem man sich befindet. Um also mein Skript beispiel.sh auszuführen müsste ich den kompletten Pfad angeben…

otto@computer:~$ cd tmp
otto@computer:~/tmp$ /home/otto/tmp/beispiel.sh
Dies ist nur ein Beispiel für ein Skript.
otto@computer:~/tmp$ $HOME/tmp/beispiel.sh
Dies ist nur ein Beispiel für ein Skript.
otto@computer:~/tmp$ ~/tmp/beispiel.sh
Dies ist nur ein Beispiel für ein Skript.

Wie Ihr seht gibt es zahllose Varianten den Pfad zur Datei anzugeben. Die Tipperei dabei ist recht aufwändig, daher gibt es Abkürzungen, die einem die Arbeit etwas abnehmen. Die kürzeste Variante einen Pfad zum aktuellen Verzeichnis anzugeben ist dabei der Punkt. Der Punkt steht für das aktuelle Verzeichnis und daher reicht zum Ausführen der beispiel.sh eben der ./ als Pfadangabe aus…

otto@computer:~$ cd tmp
otto@computer:~/tmp$ ./beispiel.sh
Dies ist nur ein Beispiel für ein Skript.

Warum ist das aktuelle Verzeichnis nicht im Pfad?

Ihr stellt euch nun eventuell die Frage warum das aktuelle Verzeichnis nicht im Pfad steckt. Man würde sich doch immer etwas Tipparbeit und vor allen Dingen Verwirrung ersparen. Der Grund ist simpel: Sicherheit! Stellt euch vor jemand gibt euch ein paar Daten, die ihr via Shell irgendwo hin verschieben sollt. In den Daten steckt jedoch noch eine kleine unscheinbare Datei namens mv mit dem Inhalt…

#!/bin/bash
rm -rf $HOME

Geht ihr nun in das Verzeichnis und setzt den Befehl…

otto@computer:~$ cd ~/daten
otto@computer:~/daten$ mv beispiel.* /wohin/auch/immer

…ab, dann würde — solange das aktuelle Verzeichnis vor /usr/bin im $PATH stehen würde — das im Verzeichnis enthaltene mv-Skript ausgeführt werden und nicht /usr/bin/mv. Das Ergebnis? Euer gesamtes Homeverzeichnis würde kommentarlos und in einem Rutsch gelöscht werden. Würde das aktuelle Verzeichnis im Suchpfad vor den Systempfaden /usr/bin und Co. im $PATH stehen, dann könnte man ohne Probleme dem Benutzer maliziöse Skripte oder gar Programme unterschieben.

Kann ich das aktuelle Verzeichnis wirklich nicht in den $PATH bekommen?

Sollte der Ausschluss des aktuellen Verzeichnisses euch wirklich sehr stören, so ist es recht problemlos möglich das aktuelle Verzeichnis in den $PATH zu packen. Ob es sinnvoll ist, das mag ich aufgrund des oben genannten Negativ-Beispieles gar nicht weiter erörtern. Den Pfad könnt Ihr über einen Eintrag in die Datei ~/.profile in eurem Homeverzeichnis individuell anpassen. Fügt Ihr am Ende der Datei beispielsweise den Eintrag…

PATH="$PATH:."

… ein und startet eine neue Shell, dann sieht euer $PATH letztendlich so aus.

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:.

Am Ende steht der . für das aktuelle Verzeichnis. Via…

otto@computer:~$ cd tmp
otto@computer:~/tmp$ beispiel.sh
Dies ist nur ein Beispiel für ein Skript.

…könnt ihr dann das Beispiel-Skript ausführen. Ihr seht, kein ./ mehr nötig. Steht der Punkt am Ende des Pfades, so besteht auch keine Gefahr dass der Trick von oben funktioniert, doch es gibt einen korrekten Weg eigene Skripte ohne Pfadangaben auszuführen.

Die Verzeichnisse ~/bin und /usr/local/bin

Ihr könnt in eurem Homeverzeichnis einen Ordner namens ~/bin anlegen. Beim Starten einer Shell wird automatisch überprüft, ob dieser Ordner existiert. Wird er gefunden, dann wird er automatisch in den $PATH aufgenommen. Dies funktioniert über den Abschnitt…

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

… in der Datei ~/.profile, die beim Starten einer Shell ausgeführt wird. Schaut ihr euch den $PATH nun an, so seht ihr…

$ echo $PATH
/home/otto/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Der Ordner /home/otto/bin steht nun an erster Stelle und Skripte, die Ihr dort ablegt, werden automatisch gefunden. Soll euer Skript oder kleines Programm von allen Benutzern des Systems verwendet werden, dann solltest ihr es nach /usr/local/bin kopieren oder dort verlinken. Dieses Verzeichnis befindet sich auch immer im $PATH und die Paketverwaltung legt dort nie Daten oder Dateien ab. Es ist also euer kleines Reich.