Ich habe versucht, mein CGI-Skript zu debuggen, das mit der Zeile begann:
#!/usr/bin/env python3
Das Problem bestand natürlich darin, dass die Umgebungsvariablen (insbesondere $PATH) von Apache HTTPd und meiner Shell unterschiedlich waren.
Nach einigem Suchen habe ich herausgefunden, dass die Systemebene .profilefür die Shell die $PATHdurch Aufrufen von festlegt /usr/libexec/path_helper. Ich habe dies überprüft, indem ich aufgerufen /usr/libexec/path_helperund die Ausgabe mit der Ausgabe von verglichen habe echo $PATH.
Der Pfad von Apache HTTPd weicht von diesem Wert ab. Dies lässt mich annehmen, dass HTTPd den Wert $PATHmanuell einstellt.
Meine Frage ist: Warum? Warum sollte ein Prozess $PATHmanuell eingestellt werden? Ich nehme an, das /usr/libexec/path_helperist eine Art Systemstandard, oder?
Die Frage ist also, warum ein Prozess $PATHmanuell festgelegt wird, anstatt eine Art Standard auf Systemebene aufzurufen, der /usr/libexec/path_helperwie ein Standard auf Systemebene aussieht.
Antwort1
/usr/libexec/path_helperIch habe es nur unter Mac OS X gesehen. Daemons (und auch Cron) unter Unix verwenden normalerweise nicht dieselbe Umgebung (und auch nicht dieselbe Konfiguration) wie die Shell. Es besteht also eine bemerkenswerte Trennung zwischen interaktiven Shells (für die Apple eine automatische Konfiguration bereitstellt) und Daemons (insbesondere jenen, die nicht von Apple verwaltet werden).
Tatsächlich könnte es sehr schlimm sein, wenn ein Netzwerk-Daemon einen neuen Pfad auswählt, weil ein Benutzer zum Experimentieren ein beliebiges Paket installiert hat, und der Netzwerk-Daemon dann plötzlich das falsche Tool vom falschen Pfad aus aufruft ... oder vielleicht benötigt der Netzwerk-Daemon eine bestimmte Version der Software X und nicht die aus dem systemweiten Pfadsystem ...
(Ich deaktiviere es übrigens komplett /usr/libexec/path_helpund stelle PATHalles manuell ein, aber ich weiß mehr oder weniger, welche Schwierigkeiten ich mir damit einstelle.)