Anfängerfrage zur Umgebungsvariable PATH in Linux Ubuntu Server?

2 Antworten

Vom Fragesteller als hilfreich ausgezeichnet

PATH hat grundsätzlich die Form:

pfad1:pfad2:pfad3

Jeder Pfad ist durch Doppelpunkte getrennt.

Ein relativ standardmäßiger PATH sieht so aus:

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

Er sucht also in den Verzeichnissen, in denen der Paketmanager oder selbst kompillierte software via make install, standardmäßig abgelegt werden.

Willst du den PATH um das aktuelle verzeichnis erweitern muss es also lauten:

PATH=/bin:/sbin/:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local:/sbin:.

Bedenke dabei 2 Dinge:

  1. Nicht grundlos ist eine solche Konfiguration kein Standard. Es kann ein Sicherheitsproblem darstellen
  2. Je nach Distribution wird der Pfad an verschiedenen Stellen gesetzt, je nach Kontext. Am sichersten würdest du gehen, wenn du in deiner $HOME/.profile Datei schreibst:
PATH="$PATH:."

Damit stellst du sicher, dass du den vom System gesetzten Pfad nicht kaputt machst.

Woher ich das weiß:Berufserfahrung – Berufserfahrung

Tichuspieler 
Fragesteller
 31.05.2023, 11:07

Heiho,

danke auch Dir für Deine Antwort, die mich allerdings etwas irritiert. Laut meinem Lehrbuch (Linux-Server für Einsteiger) sieht meine Verzeichnisstruktur aber etwas anders aus. Die Angabe, die rechts bei Dir aufgeführt ist, steht bei mit im Lehrbuch auf der linken Seite, also:

  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 

Jetzt weiß ich nicht, ob da ein Fehler im Buch vorliegt :-/

Das mit dem PATH="$PATH:." steht auch so im Buch, allerdings etwas anders, nämlich $ export PATH=$PATH:."


0
TheQ86  31.05.2023, 11:16
@Tichuspieler

Nein, das Buch ist schon korrekt. Ich hab das jetzt einfach so aus dem Kopf hingeschrieben. Der Grund ist, wie in meinem Kommentar zur anderen Antwort geschrieben, dass die Reihenfolge eine Rolle spielt.

Liegt ein Programm mit dem selben Namen in mehreren Pfaden, wird das Programm aus dem Verzeichnis genommen, das zuerst, also weiter links steht.

Ebenfalls ist das Beispiel mit dem EXPORT korrekt. Das sorgt dafür, dass auch die Programme, die du dann aufrufst den selben PATH verwenden.

Dass das Lehrbuch aber nichts dazu sagt, dass man das nicht tun sollte stört mich etwas. Auf jeden Fall solltest du, wenn du das machst, den . nicht VOR $PATH setzen. Weil das bedeuten würde, dass er alles was ganz links steht auch zuerst nimmt.

Stell dir vor, du lädst etwas aus dem Internet. zB. eine Zip-Datei mit einem Programm. Du gehst in das Verzeichnis (zB. mit cd verzeichnis) und willst anschließend mit ls schauen, was in diesem Verzeichnis liegt. Soweit so gut, du denkst dir nix dabei. Falsch konfiguriert müsste jemand jetzt nur ein Programm namens ls in dieses Verzeichnis legen, das außer den Inhalt anzuzeigen auch noch böse Dinge tut.

0
Tichuspieler 
Fragesteller
 31.05.2023, 11:23
@TheQ86

Oh, das habe ich etwas unglücklich formuliert. Tatsächlich steht im Buch, dass es aus Sicherheitsgründen keinen Punkt mehr gibt, weil es möglich ist, Programme an ungeschützten Stellen unterzubringen. Und das es nicht möglich für normale Anwender ist, die normalen Pfade zu beschreiben.
Das war mein Fehler.

Durch Deine Erklärung aber weiß ich jetzt auch, dass ein böser Mensch dann zum Beispiel ein Programm zum Beispiel mit dem Namen ls -l.sh schreiben kann, dass Böses tut und Linux sagt: Ach, da ist er ja schon, der Befehl, führt ihn aus und ich darf dann alles neu machen.

0

Wenn du ein Beispielsweise ein Skript ausführen möchtest, musst du ./skriptname eingeben. Gruß

Woher ich das weiß:eigene Erfahrung

Tichuspieler 
Fragesteller
 31.05.2023, 10:43

Danke erst einmal für Deine Antwort.
Das heißt also, wenn ich ein Programm suche, dann durchsucht Linux ja ersteinmal alle (vorgegebenen) Verzeichnisse, die es im PATH gibt. Und wenn ich ein spezielles Programm benötige, dann würde dass mittels des ./Skriptname also temporär an die Verzeichnisse angehängt?

0
TheQ86  31.05.2023, 10:51
@Tichuspieler
dann würde dass mittels des ./Skriptname also temporär an die Verzeichnisse angehängt?

Nein. Du musst unterscheiden zwischen 2 grundsätzlichen Dingen

  1. Liegt es im PATH, oder nicht
  2. Rufst du das Programm mit relativem oder absolutem Pfad auf

Generell kannst du Programme IMMER mittels ihres absoluten (kompletten) oder relativen (bezogen auf dein aktuelles Verzeichnis) Pfades aufrufen. Beispielsweise:

/home/user/meinscript.sh kannst du aus jedem Verzeichnis aufrufen

Wenn du in /home bist, kannst du aber auch user/meinscript.sh aufrufen.

Der PATH kommt erst dann ins Spiel, wenn du einen Befehl völlig ohne Angabe eines Pfades eingibst. Dann sucht er in der Reihenfolge der Definition den PATH ab.

Der Grund, dass ./meinscript.sh funktioniert ist, dass deine Shell den . intern zum aktuellen absoluten Pfad auflöst und es somit der selbe Aufruf ist, wie /home/user/meinscript.sh

An den Pfad hängt diese Schreibweise also nichts an.

2
Tichuspieler 
Fragesteller
 31.05.2023, 11:16
@TheQ86

Okay. Jetzt weiß ich, dass es so etwas wie absoluter Pfad und relativer Pfad gibt (war mir bisher nicht bekannt)

Wenn ich Dich jetzt richtig verstanden habe, kann ich dem Linuxsystem sagen:

Liebes Linuxsystem, ich möchte, dass Du den Befehl ls -l ausführst, den findest du da und da, und dann läuft Linux dorthin, findet ihn und führt ihn aus.
Wenn ich jetzt aber nur schreibe ls -l, dann stöhnt Linux auf, macht sich aber zähneknirschend daran, jedes seiner Verzeichnisse zu durchsuchen, bis er den Befehl findet und führt ihn dann aus.

Das mit dem Grund, dass ./meinskript.sh funktioniert, habe ich verstanden. Vielen lieben Dank für die sehr gute Erklärung :-)

0