it-swarm.com.de

Warum benötigen Sie ./ (Punkt-Schrägstrich) vor dem Namen der ausführbaren Datei oder des Skripts, um sie in Bash auszuführen?

Beim Ausführen von Skripten in Bash muss ich am Anfang ./ Schreiben:

$ ./manage.py syncdb

Wenn nicht, erhalte ich eine Fehlermeldung:

$ manage.py syncdb
-bash: manage.py: command not found

Was ist der Grund dafür? Ich dachte, . Ist ein Alias ​​für den aktuellen Ordner, und daher sollten diese beiden Aufrufe gleichwertig sein.

Ich verstehe auch nicht, warum ich zum Ausführen von Anwendungen ./ Nicht benötige, wie zum Beispiel:

user:/home/user$ cd /usr/bin
user:/usr/bin$ git

(was ohne ./ läuft)

264
Dan Abramov

Unter Unix befindet sich das aktuelle Verzeichnis normalerweise nicht in $PATH.

Wenn Sie einen Befehl eingeben, durchsucht die Shell eine Liste von Verzeichnissen, wie in der Variablen PATH angegeben. Das aktuelle Verzeichnis befindet sich nicht in dieser Liste.

Der Grund dafür, dass das aktuelle Verzeichnis nicht in dieser Liste enthalten ist, ist die Sicherheit.

Nehmen wir an, Sie sind root und gehen in das Verzeichnis eines anderen Benutzers und geben sl anstelle von ls ein. Befindet sich das aktuelle Verzeichnis in PATH, versucht die Shell, das Programm sl in diesem Verzeichnis auszuführen (da es kein anderes Programm sl gibt). Dieses sl Programm ist möglicherweise bösartig.

Es funktioniert mit ./, Da POSIX spezifiziert ein Befehlsname, der einen / Enthält, direkt als Dateiname verwendet wird, wodurch eine Suche in $PATH Unterdrückt wird. . Sie hätten den vollständigen Pfad für genau denselben Effekt verwenden können, aber ./ Ist kürzer und einfacher zu schreiben.

[~ # ~] edit [~ # ~]

Dieser sl Teil war nur ein Beispiel. Die Verzeichnisse in PATH werden nacheinander durchsucht, und wenn eine Übereinstimmung hergestellt wird, wird dieses Programm ausgeführt. Je nachdem, wie PATH aussieht, reicht die Eingabe eines normalen Befehls möglicherweise nicht aus, um das Programm im aktuellen Verzeichnis auszuführen.

288
cnicutar

Wenn bash die Befehlszeile interpretiert, sucht es nach Befehlen an Stellen, die in der Umgebungsvariablen $PATH Beschrieben sind. Um es zu sehen, tippe:

echo $PATH

Sie werden einige durch Doppelpunkte getrennte Pfade haben. Wie Sie sehen werden, befindet sich der aktuelle Pfad . Normalerweise nicht in $PATH. Bash kann Ihren Befehl also nicht finden, wenn er sich im aktuellen Verzeichnis befindet. Sie können es ändern, indem Sie:

PATH=$PATH:.

Diese Zeile fügt das aktuelle Verzeichnis in $PATH Hinzu, so dass Sie Folgendes tun können:

manage.py syncdb

Es wird nicht empfohlen, da es ein Sicherheitsproblem gibt. Außerdem kann es zu seltsamen Verhaltensweisen kommen, da . Sich je nach Verzeichnis unterscheidet, in dem Sie sich befinden :)

Vermeiden:

PATH=.:$PATH

Wie Sie einige Standardbefehle "maskieren" und die Tür für Sicherheitsverletzungen öffnen können :)

Nur meine zwei Cent.

49
neuro

Ihr Skript wird in Ihrem Ausgangsverzeichnis nicht gefunden, wenn die Shell die Umgebungsvariable $PATH Überprüft, um Ihr Skript zu finden.

Das ./ Zeigt an, dass im aktuellen Verzeichnis nach meinem Skript gesucht wird, anstatt alle in $PATH Angegebenen Verzeichnisse zu durchsuchen.

40
mdm

Wenn Sie das '.' Sie geben im Wesentlichen den "vollständigen Pfad" zum ausführbaren Bash-Skript an, sodass Ihre Shell Ihre PATH-Variable nicht überprüfen muss. Ohne das '.' Ihre Shell sucht in Ihrer PATH-Variablen (die Sie sehen können, indem Sie echo $PATH, um festzustellen, ob der von Ihnen eingegebene Befehl in einem der Ordner auf Ihrem PATH gespeichert ist. Wenn dies nicht der Fall ist (wie es bei manage.py der Fall ist), wird angegeben, dass die Datei nicht gefunden werden kann. Es wird als schlechte Praxis angesehen, das aktuelle Verzeichnis in Ihren PATH aufzunehmen, was hier einigermaßen gut erklärt wird: http://www.faqs.org/faqs/unix-faq/faq/part2/section-13.html)

5
Mark Drago

Unter * nix befindet sich das aktuelle Verzeichnis im Gegensatz zu Windows normalerweise nicht in Ihrem $PATH Variable. Das aktuelle Verzeichnis wird also bei der Ausführung von Befehlen nicht durchsucht. Du brauchst nicht ./ zum Ausführen von Anwendungen, da diese Anwendungen sind in Ihrem $ PATH; höchstwahrscheinlich sind sie in /bin oder /usr/bin.

2
Anomie

Diese Frage hat bereits einige großartige Antworten, aber ich wollte hinzufügen, dass, wenn sich Ihre ausführbare Datei auf dem Pfad befindet und Sie beim Ausführen sehr unterschiedliche Ausgaben erhalten

./executable

zu denen, die du bekommst, wenn du rennst

executable

(Nehmen wir an, Sie werden mit der einen und nicht mit der anderen auf Fehlermeldungen gestoßen). Dann könnte das Problem sein, dass Sie zwei verschiedene Versionen der ausführbaren Datei auf Ihrem Computer haben: eine auf dem Pfad und die andere nicht.

Überprüfen Sie dies durch Ausführen

welche ausführbare Datei

und

whereis executable

Es hat meine Probleme behoben ... Ich hatte drei Versionen der ausführbaren Datei, von denen nur eine für die Umgebung korrekt kompiliert wurde.

1
KR_Henninger

Wenn sich das Skript nicht im Pfad befindet, müssen Sie dies tun. Weitere Informationen finden Sie unter http://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_01.html

0
Gayan Hewa