这样做的主要原因是使脚本可跨操作系统环境移植。

例如，在mingw下，python脚本使用:

#!/c/python3k/python 

在GNU/Linux发行版下，它是:

#!/usr/local/bin/python 

or

#!/usr/bin/python

在最好的商业Unix sw/hw系统(OS/X)下，它是:

#!/Applications/MacPython 2.5/python

或在FreeBSD上:

#!/usr/local/bin/python

然而，所有这些差异可以通过使用以下方法使脚本可移植:

#!/usr/bin/env python

如果安装了多个版本的Python， /usr/bin/env将确保使用的解释器是环境$PATH中的第一个解释器。另一种方法是硬编码类似#!/usr/bin/python;这是可以的，但是不太灵活。

在Unix中，要解释的可执行文件可以通过#!在第一行的开头，后面跟着解释器(以及它可能需要的任何标志)。

如果您谈论的是其他平台，当然，这条规则不适用(但“shebang行”没有害处，如果您将该脚本复制到基于Unix的平台，如Linux、Mac等，则会有所帮助)。

这被称为shebang线。维基百科词条解释道:

在计算中，shebang(也称为hashbang、hashpling、pound bang或crunchbang)指的是字符“#!”，当它们是解释器指令中作为文本文件第一行的前两个字符时。在类unix操作系统中，程序加载器将出现这两个字符作为文件是脚本的指示，并尝试使用文件中第一行剩余部分指定的解释器执行该脚本。

请参见Unix FAQ条目。

即使在Windows上，shebang行不决定要运行的解释器，您也可以通过在shebang行上指定选项来将选项传递给解释器。我发现在一次性脚本中保留一个通用的shebang行很有用(比如我在回答SO问题时写的脚本)，这样我就可以在Windows和ArchLinux上快速测试它们。

env实用程序允许你在路径上调用命令:

剩下的第一个参数指定要调用的程序名称;它根据PATH环境变量进行搜索。其余的参数将作为参数传递给该程序。

它允许你选择你想要使用的可执行文件;这是非常 如果你有多个python安装和不同的模块，这很方便 在每一个愿望中选择。如。

#!/bin/sh
#
# Choose the python we need. Explanation:
# a) '''\' translates to \ in shell, and starts a python multi-line string
# b) "" strings are treated as string concat by python, shell ignores them
# c) "true" command ignores its arguments
# c) exit before the ending ''' so the shell reads no further
# d) reset set docstrings to ignore the multiline comment code
#
"true" '''\'
PREFERRED_PYTHON=/Library/Frameworks/Python.framework/Versions/2.7/bin/python
ALTERNATIVE_PYTHON=/Library/Frameworks/Python.framework/Versions/3.6/bin/python3
FALLBACK_PYTHON=python3

if [ -x $PREFERRED_PYTHON ]; then
    echo Using preferred python $ALTERNATIVE_PYTHON
    exec $PREFERRED_PYTHON "$0" "$@"
elif [ -x $ALTERNATIVE_PYTHON ]; then
    echo Using alternative python $ALTERNATIVE_PYTHON
    exec $ALTERNATIVE_PYTHON "$0" "$@"
else
    echo Using fallback python $FALLBACK_PYTHON
    exec python3 "$0" "$@"
fi
exit 127
'''

__doc__ = """What this file does"""
print(__doc__)
import platform
print(platform.python_version())

扩展一下其他的答案，这里有一个小例子，说明你的命令行脚本会因为不小心使用/usr/bin/env shebang行而陷入麻烦:

$ /usr/local/bin/python -V
Python 2.6.4
$ /usr/bin/python -V
Python 2.5.1
$ cat my_script.py 
#!/usr/bin/env python
import json
print "hello, json"
$ PATH=/usr/local/bin:/usr/bin
$ ./my_script.py 
hello, json
$ PATH=/usr/bin:/usr/local/bin
$ ./my_script.py 
Traceback (most recent call last):
  File "./my_script.py", line 2, in <module>
    import json
ImportError: No module named json

json模块在Python 2.5中不存在。

防止这类问题的一种方法是使用通常与大多数python一起安装的版本化python命令名:

$ cat my_script.py 
#!/usr/bin/env python2.6
import json
print "hello, json"

如果你只需要区分Python 2。3. Python。x，最近发布的Python 3也提供了一个python3名称:

$ cat my_script.py 
#!/usr/bin/env python3
import json
print("hello, json")

这意味着更多的是历史信息而不是“真实的”答案。

请记住，过去有很多类似unix的操作系统，它们的设计者都有自己的想法，把东西放在哪里，有时根本不包括Python、Perl、Bash或许多其他GNU/开源的东西。

这甚至适用于不同的Linux发行版。在Linux - pre-FHS1 -你可能在/usr/bin/或/usr/local/bin/中有Python。或者它可能还没有安装，所以您构建了自己的，并将其放在~/bin中。

Solaris是我工作过的最糟糕的系统，部分原因是从Berkeley Unix到System v的过渡。你可能会在/usr/、/usr/local/、/usr/ucb/、/opt/等目录下找到东西。这可能会导致一些很长的路径。我记得从Sunfreeware.com安装每个包在自己的目录，但我不记得它是否符号链接二进制文件到/usr/bin/。

哦，有时/usr/bin/在NFS服务器2上。

所以env实用程序就是为了解决这个问题而开发的。

然后你可以写#!/bin/env解释器，只要路径是正确的，程序就有合理的运行机会。当然，合理意味着(对于Python和Perl)还设置了适当的环境变量。对于bash/ksh/zsh，它可以正常工作。

这很重要，因为人们在传递shell脚本(如Perl和Python)，如果你在Red Hat Linux工作站上硬编码/usr/bin/python，它将在SGI上坏掉……不，我认为IRIX把Python放在了正确的位置。但在Sparc空间站上，它可能根本无法运行。

我想念我的斯巴达站。但不是很多。好吧，现在你让我在易趣网上搜了。Bastages。

1文件系统层次标准。

2是的，有时候人们还是会做这样的事情。不，我的腰带上既没有萝卜也没有洋葱。