☰

Warum wird bei der Ausführung eines Programms "./" verwendet?

tag-icon • tag-icon linux bash
Warum wird bei der Ausführung eines Programms "./" verwendet?

Wenn ich ein Programm mit dem Namen foo habe, warum muss ich dann ./foo sagen und nicht einfach foo? Bedeutet ./ nicht einfach innerhalb des aktuellen Verzeichnisses?

Antwort1

Wenn Sie nur einen Befehl eingeben – z. B. – sucht foodie Shell (normalerweise ) nur in bestimmten Verzeichnissen danach – wie /bin, /usr/bin, /usr/X11R6/bin und so weiter. Normalerweisebashnichtschauen Sie aus Sicherheitsgründen in Ihrem „aktuellen Verzeichnis“ (also „.“ ) nach (besonderswenn du bistWurzel). Wenn "." hinzugefügt wird, sollte es hinzugefügt werden zudas Ende vonder Suchpfad.

Wenn Sie eine ausführbare Datei ausführen möchten, dienichtIn diesem Suchpfad müssen Sie den gesamten absoluten oder relativen Pfad zum Befehl angeben. Beispiel:

/home/bok/foo   # Absolute in my homedir

~/src/bar  # Shorthand for my homedir and a subdir in it

../Download/foobar  # Relative path – up one step, then down in Download

Oder – wenn sich der Befehl in meinem aktuellen Verzeichnis befindet – fügen Sie einfach ein ./: hinzu.

./foo

Der Suchpfad für bashbefindet sich imWEGUmgebungsvariable, Sie können sie also sehen, indem Sie Folgendes eingeben:

echo $PATH

Um "." hinzuzufügen – was Sie wirklichsollte nichttun – Typ:

export PATH="$PATH:."

Der Pfad wird der Reihe nach durchsucht. Wenn sich also mehrere ausführbare Dateien mit demselben Namen in verschiedenen Verzeichnissen befinden, führt die Shell die Datei im ersten Verzeichnis im Pfad aus.

Nachdem Sie alle aufgelisteten Verzeichnisse durchsucht haben, wird Ihnen zunächst die Fehlermeldung „Befehl nicht gefunden“ angezeigt.

+++

Das Problem beim Hinzufügen des aktuellen Verzeichnisses – .– zum PATH besteht darin, dass Sie nicht wirklich wissen, ob eine ausführbare Datei in einem „nicht standardmäßigen“ Verzeichnis, in dem Sie sich zufällig befinden, ausgeführt werden soll oder nicht.

Nehmen wir an, ich bin böse und erstelle ein zerstörerisches Programm, das so viele Dateien wie möglich löscht und sie in meinem Home-Verzeichnis – oder schlimmer noch in /tmp – belässt. Ich rufe dieses Programm auf sl– ein häufiger Fehlertyp ls– und warte.

Ein beliebiger Benutzer befindet sich in /tmp und schreibt falsch lsmit sl. Mit einem normalen PATH – ohne . – passiert nichts, außer dass er eine Fehlermeldung für „Befehl nicht gefunden“ erhält. Wenn er am Ende seines PATHs einen . hat, erhält er keine Fehlermeldung für die Eingabe des Befehls. Stattdessen slwird mein Befehl ausgeführt und löscht alle Dateien, die ihm gehören. Wenn er zufälligWurzelkann der Befehl einen Großteil des Systems löschen. (Aus diesem GrundWurzel sollte wirklichmachen Sie es zur Regel,stetsverwenden Sie dievollständigen Pfadvon Befehlen, anstatt PATH zu vertrauen.)

Wenn er '.' an den Anfang seines PATH gesetzt hätte und ich ein Programm namens ls(korrekte Schreibweise) erstellt und in ein Verzeichnis gelegt hätte, dann wäre esMeinProgramm – nicht das normale ls– das ausgeführt würde, wenn er lsin dieses Verzeichnis eintippte. Denn es bashwürde im aktuellen Verzeichnis suchen (.)Erste– bevor Sie in den Systemverzeichnissen mit der Originaldatei nachsehen ls.

verwandte Informationen