Ich habe ein Dutzend verschiedene Antworten gelesen und mit einer Reihe von Leuten gesprochen und habe Schwierigkeiten zu verstehen, wie PATH in verschiedenen Szenarien berechnet wird. Konkret denke ich an
Außerdem bin ich jetzt auf High Sierra, aber ich sehe einige Leute, die erwähnt haben, dass sich dies irgendwann geändert hat?
Ich habe diese und diese Antwort gesehen, aber beide scheinen sich explizit darauf zu konzentrieren, was innerhalb von bash passiert.
Ich werde 1 & 2 zusammenfassen, weil alle Shells Dateien beim Start lesen.
PATH wird von seinem übergeordneten Prozess geerbt. Dies ist ein Schlüsselkonzept, das Sie verstehen müssen.
Der PATH wird zuerst fest in den Kernel codiert:
sysctl user.cs_path
user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin
launchd, das so funktioniert, init
kann konfiguriert werden, um diesen PATH zu ändern. Im Allgemeinen wird es nicht geändert.
Die loginwindow.app richtet eine Umgebung ein, wenn Sie sich bei Ihrem Computer anmelden. PATH wird überprüft, ob es gesetzt wurde, oder es wird auf den hartcodierten Pfad im Kernel oder einen modifizierten Pfad gesetzt, der von launchd gesetzt wurde. Es ist, als würde die loginwindow.app anrufen login -pf <username>
.
An diesem Punkt kann ein Benutzer LaunchAgent oder LaunchDaemon den PATH ändern.
Dies ist der PFAD, der GUI-Anwendungen im Finder zur Verfügung steht. (Frühere Versionen von OS X konnten ~/.MacOSX/environment.plist verwenden, um den PFAD für GUI-Anwendungen zu ändern). Nun, wenn dies kompliziert erscheint, ist es nicht und wahrscheinlicher, wie ich, der PATH verfügbar ist/usr/bin:/bin:/usr/sbin:/sbin
Wenn Sie die Terminal.app starten, ruft sie zuerst login
(login -pf ) auf, was dazu führt, dass Ihre Shell als Login-Shell behandelt wird. Die entsprechenden Dateien in /etc und Ihrem HOME-Ordner werden gelesen. Jetzt sollte PATH anders sein als von der loginwindow.app festgelegt. Erinnerst du dich, dass wir über Erbschaft gesprochen haben? Wenn Sie eine GUI-App von Ihrer Terminalsitzung aus starten, ist der für die GUI-Anwendung verfügbare PATH derselbe wie von der Shell festgelegt.
Daemons werden normalerweise mit ihrem absoluten Pfad gestartet.
Aus der Manpage für PATH ( man path
):
Der Suchpfad für Befehle. Es ist eine durch Doppelpunkte getrennte Liste von Verzeichnissen, in denen die Shell nach Befehlen sucht (siehe BEFEHLSAUSFÜHRUNG weiter unten).... Der Standardpfad ist systemabhängig und wird vom Administrator festgelegt, der Bash installiert. Ein häufiger Wert ist ``/usr/gnu/bin:/usr/local/bin:/usr/ucb:/bin:/usr/bin''.
Abgesehen von der Bash-Manpage sehen wir also, dass der Bash-Pfad (zunächst) so lautet:
Der Pfad kann (offensichtlich) geändert werden. Es gibt mehrere Stellen, an denen die Umgebungsvariable PATH gesetzt werden kann:
~/.bashrc
~/.bash_profile
In macOS wird die Datei /etc/paths
verwendet, um die Suchpfade zu konfigurieren:
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
Außerdem wird der Pfad anfänglich durch das Dienstprogramm konfiguriert, /usr/libexec/path_helper
das einen Pfad basierend auf dem Inhalt von erstellt/etc/paths.d
Es wird aufgerufen, von /etc/profile
dem aus das systemweite Bash-Profil festgelegt wird (individuelle werden in festgelegt ~/.profile
) .
Bei GUI-Apps hat der Shell-Pfad wirklich keine Auswirkung. Das einzige Mal, wenn eine GUI-Anwendung (Cocoa, Quartz, Metal) irgendetwas mit PATH zu tun hat, ist, wenn sie eine Shell öffnet (entweder interaktiv oder nicht interaktiv). An diesem Punkt wird es die PATH-Umgebung wie festgelegt verwenden oder alle erforderlichen Änderungen zur Laufzeit vornehmen.
Jede der Shells hat ein anderes systemweites Profil (wie bash), das den anfänglichen PATH festlegt (durch Aufrufen des path_helper
Dienstprogramms).
/etc/zprofile
/etc/profile
/etc/csh.login
system attribute PATH
oder etwas in AppleScript tun, oder? Der Wert, den ich dort sehe ... wo kommt er her? Welche Reihe von Schritten hat das Betriebssystem durchlaufen, um es einzustellen?Alle: Bitte haben Sie Verständnis dafür, dass Apple das Pfadparadigma im Laufe der Zeit in Sierra (siehe https://lluad.com/blog/os-x-system-path/ ), HighSierra und Mojave geändert hat. Path_helper funktioniert jetzt anscheinend etwas anders, weil es Terminalfenster für mich gesperrt hat, die ich durch Auskommentieren freigeben und gut funktionieren lassen kann
# if [ -x /usr/libexec/path_helper ]; then
# eval `/usr/libexec/path_helper -s`
# fi
im /etc/profile
.
Ich habe Skripte, die den Pfad reparieren, weil ich mehrere Tools habe (der Kern davon wird von Homebrew installiert, aber das sind nur etwa 15 der 25, die ich jeden Tag verwende) und diese müssen für die Verwendung in .app eingestellt werden Anwendungen, in .sh-Skriptstarts und für den automatischen Start in geschützter Boot-Sequenz unter Mojave. Es ist verwirrend, aber sicher hat Mojave die erforderliche Struktur geändert und ich muss sie selbst verbessern.
Für diese spezielle Frage bedeutet dies, dass die Frage in ihrer ganzen Breite relevant ist und von Entwicklern beantwortet werden muss, die den Schmerz gespürt und ihre Systeme für Mojave repariert haben und auch aus den verschiedenen „Welten“ kommen, wie normale IDEs , XCode, Eclipse, Bean, Intellij usw. Auch diejenigen, die auf Homebrew-Stacks oder Mamp-Stacks usw. angewiesen sind. Und für diejenigen, die mit Docker, .node, vm usw. und anderen tieferen Tools arbeiten. Wenn Apple mehr Sicherheit implementiert, werden unsere Sachen kaputt gehen, aber ich bin froh, dass Apple seinen Job macht. Wir müssen unsere tun, also brauchen wir führende Leute, um die neue Weisheit weiterzugeben. Artikel, die 6 oder mehr Monate alt sind, werden uns nur verwirren.
Allan
Georg Mauer
.bash_profile
zum Beispiel so, weil PATH zu dem Zeitpunkt, an dem die Zeit läuft, bereits Dinge enthält (deshalb fügen wir vorne oder hinten hinzu). Es wird berechnet, indem eine Reihe von Quellen berücksichtigt und eine Reihe von Skripten ausgeführt werden, aber was sind das ?Benutzer3439894
Georg Mauer
Harald Hanche-Olsen
path_helper
um die PATH-Variable zu setzen. Sehen Sie sich die Handbuchseite an; Sie werden feststellen, dass sie lesen/etc/paths
und/etc/paths.d/*
für den Inhalt. Benutzer anderer Shells sind gut beraten, diese Methode anzupassen; Auf diese Weise erhalten alle Shells denselben PATH.