多くの場合、スクリプト#!/usr/bin/env interpreter_nameはすべてのインタープリターに使用するシバン行で始まり、さまざまなシステムがさまざまな場所にインストールして実行するために必要なインタープリターを備えているという根拠があります。たとえば、のようにpythonインストールされていると仮定/usr/bin/pythonすると/opt/python、何らかの理由でインストールを決定したユーザーは、簡単に使用できなくなります。
しかし、明らかな質問は、（またはその問題に関しては特定の場所に）envインストールされる保証があるのか/usr/bin/env、それとも、いわば「問題を移動する」場合に過ぎないのか、ということです。
このわずかに関連する質問には、それは悪いアイデアであり、インタープリターの実際のパスを使用してインストールすることが望ましいというコメントがあり、単一のUNIX仕様を引用していますが、この質問には実際には触れていません。
回答:
いいえ、シバンメカニズムの履歴のセクション「The envユーティリティ」で読むことができるenvので、にあることが保証されていません：/usr/bin
ただし、env（1）の場所は異なる場合があります。Free-、Net-、OpenBSDおよび一部のLinuxディストリビューション（Debianなど）には/ usr / bin / envのみが付属しています。一方で、少なくともSCO OpenServer 5.0.6とCray Unicos 9.0.2には/ bin / envしかありません（後者は歴史的にのみ重要です）。他の一部のLinuxディストリビューション（Redhat）では、/ binにあり、/ usr / bin /にはそれを指すシンボリックリンクが含まれています。
env検索の柔軟性のため、問題が完全に解決するわけではありません$PATH。env自分の場所とは異なる場所を使用するスクリプトを入手した場合は、住んでいる場所を知るだけでよく、、、およびその他のインタープリターがenvどこperlにpythonインストールされているかも知る必要はありません。
そして/opt/python/3.3.2/bin/python3.3、それがpython3.3PATHの最初の実行可能ファイルである場合は、ハードコードする必要はありません。あなただけに頼ることができるenvあなたが/opt/python/3.3.3/bin/python3.3を使用するようにアップグレードする場合はそれぞれ、すべてのスクリプトを更新する必要はありませんので、それを見つけます。スクリプトヘッダーは同じままです。
#! /usr/bin/env python3.3
pythonperl他のものを探す代わりに、あなたは今捜し出さなければならないだけなenvので、同じ問題ですが、異なる対象です。それはそれenvを見つけるのがはるかに簡単であり、明らかにはるかに用途が広いので、それでも非常に有利です。それは私の質問に完全に答えます。ありがとうございました！