我在Python文件的顶部看到了这些:
#!/usr/bin/env python
#!/usr/bin/env python3
在我看来,没有这一行,文件运行是一样的。
我在Python文件的顶部看到了这些:
#!/usr/bin/env python
#!/usr/bin/env python3
在我看来,没有这一行,文件运行是一样的。
当前回答
在我看来,没有这一行,文件运行是一样的。
如果是这样,那么也许你是在Windows上运行Python程序?Windows不使用这一行——相反,它使用file-name扩展名来运行与文件扩展名相关的程序。
然而,在2011年,一个“Python启动器”被开发出来,它(在某种程度上)在Windows上模仿了Linux的这种行为。这仅限于选择运行哪个Python解释器——例如,在安装了Python 2和Python 3的系统中选择Python 2和Python 3。在Python安装时,启动器可选地作为py.exe安装,并且可以与.py文件相关联,以便启动器将检查这一行,然后启动指定的Python解释器版本。
其他回答
执行python文件时,可以使用./file.py,其中file是文件的名称。/usr/bin/env是PATH,然后python是python2, python3是python3(胡说)
#!/usr/bin/env python也可以允许python文件被其他程序执行,只要使用chmod +x file.py即可。
它允许你选择你想要使用的可执行文件;这是非常 如果你有多个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())
这意味着更多的是历史信息而不是“真实的”答案。
请记住,过去有很多类似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是的,有时候人们还是会做这样的事情。不,我的腰带上既没有萝卜也没有洋葱。
强调一件大多数人都忽略了的事情可能是有道理的,这可能会妨碍立即理解。在终端中输入python时,通常不会提供完整路径。相反,可执行文件在PATH环境变量中查找。反过来,当你想直接执行Python程序/path/to/app.py时,必须告诉shell要使用哪个解释器(通过hashbang,其他贡献者在上面解释的内容)。
Hashbang期望到解释器的完整路径。因此,要直接运行你的Python程序,你必须提供Python二进制文件的完整路径,这差异很大,特别是考虑到使用virtualenv。为了解决可移植性,使用了/usr/bin/env的技巧。后者最初的目的是就地改变环境并在其中运行命令。当没有提供任何更改时,它将在当前环境中运行该命令,这将有效地导致相同的PATH查找。
源代码来自unix stackexchange
考虑到python2和python3之间的可移植性问题,您应该始终指定其中一个版本,除非您的程序与两个版本都兼容。
一些发行版现在已经发布了python符号链接到python3 -不要依赖于python是python2。
PEP 394强调了这一点:
为了容忍不同平台的差异,所有的新代码 需要调用Python解释器时不应该指定Python,但是 而是应该指定python2或python3(或更具体的 python2。X和python3。x版本;参见迁移说明)。这 当从shell调用时,应该在shebangs中进行区分 脚本,当通过system()调用调用时,或在任何 其他上下文。