我经常会看到脚本以#!/usr/bin/env interpreter_name用于任何解释器的 shebang 行开头，理由是不同的系统可能具有它们需要的解释器，以便在不同的地方运行。例如，如果我假设python已安装，/usr/bin/python那么某些/opt/python出于某种原因决定安装它的用户将无法轻松使用它。
但显而易见的问题是，是否有任何保证env将安装在/usr/bin/env（或就此而言任何特定的地方），或者这只是“移动问题”的一个案例？
这个稍微相关的问题有一条评论说这是一个坏主意，最好使用解释器的实际路径安装它并引用单个 unix 规范，但并没有真正解决这个问题。
不，env不能保证在 中/usr/bin，正如您可以在shebang 机制的历史中阅读的“环境实用程序”部分：
但是，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