Gibt es eine Garantie dafür, dass / usr / bin / env existiert?

Oft sehe ich, dass Skripte mit einer Shebang-Zeile beginnen, die #!/usr/bin/env interpreter_namefür jeden Interpreter verwendet wird, mit der Begründung, dass verschiedene Systeme möglicherweise den Interpreter haben, den sie benötigen, um an verschiedenen Orten installiert zu werden. Wenn ich zum Beispiel davon ausgehe, dass pythones installiert /usr/bin/pythonist, kann ein Benutzer, der sich /opt/pythonaus irgendeinem Grund für die Installation entschieden hat, es nicht so einfach verwenden.

Die offensichtliche Frage ist jedoch, ob es eine Garantie envgibt, die an /usr/bin/enveinem bestimmten Ort (oder an einem bestimmten Ort) installiert wird, oder ob es sich sozusagen nur um einen Fall handelt, bei dem das Problem verschoben wird.

Diese leicht verwandte Frage enthält einen Kommentar, der besagt, dass es sich um eine schlechte Idee handelt. Es ist vorzuziehen, sie mit dem tatsächlichen Pfad des Interpreters zu installieren. Sie zitiert die einzelne Unix-Spezifikation, geht jedoch nicht wirklich auf diese Frage ein.

Nein, es envist nicht garantiert, dass /usr/binSie dabei sind, wie Sie in der Geschichte des Shebang-Mechanismus im Abschnitt "Das env-Dienstprogramm" nachlesen können :

Die Position von env (1) kann jedoch variieren. Free-, Net-, OpenBSD und einige Linux-Distributionen (z. B. Debian) werden nur mit / usr / bin / env geliefert. Auf der anderen Seite gibt es mindestens / bin / env zumindest auf SCO OpenServer 5.0.6 und Cray Unicos 9.0.2 (obwohl letzteres nur von historischem Interesse ist). Bei einigen anderen Linux-Distributionen (Redhat) befindet es sich in / bin und / usr / bin / enthält einen symbolischen Link, der darauf verweist.

Das Problem wird aufgrund der Flexibilität der envSuche nicht vollständig verschoben $PATH. Wenn Sie einige Skripte bekommen passieren, der für einen anderen Ort verwenden envvon Ihnen, Sie nur darüber haben , wo Ihr wissen , envlebt, und auch nicht , wo perl, pythonund andere Dolmetscher könnten installiert werden.

Und Sie müssen nicht hart codieren, /opt/python/3.3.2/bin/python3.3wenn dies die erste python3.3ausführbare Datei in Ihrem PATH ist. Sie können sich einfach darauf verlassen env, es zu finden, sodass Sie nicht jedes einzelne Skript aktualisieren müssen, wenn Sie ein Upgrade auf /opt/python/3.3.3/bin/python3.3 durchführen. Ihr Skript-Header bleibt gleich:

#! /usr/bin/env python3.3