我应该把shebang放到Python脚本中吗?以什么形式?
或
这些东西同样可以携带吗?哪种形式最常用?
注:龙卷风项目使用shebang。另一方面,Django项目没有。
- 第二种是不可移植的,如果不是大多数的话,在许多计算机上都会发生故障。
- 与第一个选项相比,#!/usr/bin/python是如何进行的?我在很多示例代码中看到了这一点。编辑:也许这就是答案。stackoverflow.com/a/2429517/1156245
- 可能是人们为什么要写的副本!/在python脚本的第一行使用usr/bin/env python?
- 我说总是用它,为什么?"python的禅"—第2行-"显式优于隐式。"python.org/dev/peps/pep-0020
- 坦率地说,两者都不是"对的",因为作为作者,您不知道运行脚本时,正确的Python版本将在哪里。安装人员的工作应该是添加正确的shebang。
任何脚本中的shebang行决定了脚本像独立的可执行文件一样执行的能力,而无需事先在终端中键入python,也无需在文件管理器中双击(如果配置正确)。这是不必要的,但通常放在那里,所以当有人看到在编辑器中打开的文件时,他们会立即知道他们在看什么。但是,您使用的是哪条shebang线很重要。
python 3脚本的正确用法是:
默认为3.latest版本。对于python 2.7.最新使用python2代替python3。
不应使用以下代码(除了编写与python 2.x和3.x兼容的代码的罕见情况):
PEP 394中给出这些建议的原因是,python可以指不同系统上的python2或python3。目前,它在大多数发行版上指的是python2,但在某些时候可能会有所改变。
另外,不要使用:
"python may be installed at /usr/bin/python or /bin/python in those
cases, the above #! will fail."
——"啊!/usr/bin/env python"vs"!/usr/local/bin/python"
- @eliasvanootegem如果你不能确定会在/usr/bin中找到python,那么你怎么能确定env会在/usr/bin中找到。如果将python安装在非标准位置,那么很可能意味着python是以非标准方式安装的,因此脚本应该很快失败。而不是对python解释器的属性进行假设,并希望得到最好的结果。
- @沙丘:env经常出现在/usr/bin/中,它的工作是使用PATH定位垃圾箱(如python)。无论如何安装python,它的路径都将添加到这个变量中,并且env将找到它(如果没有,则没有安装python)。这就是env的工作,这就是它存在的全部原因。它提醒环境(设置env变量,包括安装路径和include路径)。人们总是明白,只有在同一个地方找到这个命令,它才能工作。那只是给你的
- 做谷歌搜索(我做了,只是为了安全起见):没有一个案例是env放错了位置。另一方面,你很快就会发现/usr/bin/python、/bin/python或/usr/local/bin/python离安装python的唯一位置(如:$HOME/bin/python远),只需看看你定义了多少路径(echo $PATH)。
- @我犯了个错误。我不知道env是posix标准的一部分。我认为env并不总是POSIX标准的一部分,所以我一直在努力接受过时的建议。
- @沙丘:我怀疑ENV最迟是在1992年加入的,当时壳牌公司和公用事业公司也加入了这个标准。如果我没弄错,那么是的,你真的得到了一些过时的建议
- @Eliasvanootegem:我不知道posix授权env在/usr/bin/中的位置。
- @J.F.Sebastian:你是对的,它没有保证,也没有被POSIX标准强制执行。我认为这是因为后来的一个IEEE版本确实包含了一些环境方面的内容。任何一种方式:不,除了广泛(普遍?)之外,任何标准都不能保证/usr/bin/env。采用的规则…
- @J.F.Sebastian:posix也没有指定shebang。解释初始#!行的系统将其作为POSIX标准的扩展。然而,这并不能阻止人们假设shebangs会一直工作。
- @理查德汉森:你是说所有支持舍班人的系统都支持/usr/bin/env吗?就个人而言,只要在pylauncher运行的任何系统上都能运行/usr/bin/env就足够了(windows通过pylauncher支持/usr/bin/env的shebang)
- @J.F.塞巴斯蒂安:不,我只是说,无论是#!还是/usr/bin中的env都不是由POSIX指定的,但是它们都得到了广泛的支持。假设#!/usr/bin/env python可以正常工作,即使#!/usr/bin/env的内容没有被posix标准化。
- 如果您使用的是virtualenv,!/usr/local/bin/python,即使它存在,也会出错。
- 有一个问题:根据PEP394,当脚本与python 2和python 3兼容时,应该只使用python可执行文件。否则,应该从python2和python3中选择合适的选项。
- 在arch linux上,python是python3
- 至少在debian上,您应该使用python二进制文件的直接路径,而不是env:bugs.debian.org/cgi-bin/bugreport.cgi?Bug=751817×10
- 如果您想使用父环境的设置来启用env来选择python,那么#!/usr/bin/env python表单是很好的。如果需要脚本使用特定的python可执行文件或虚拟环境,则应将其路径放在shebang中。
这真的只是品味问题。添加shebang意味着人们可以根据需要直接调用脚本(假设它被标记为可执行);省略它只意味着必须手动调用python。
运行程序的最终结果不会受到任何影响;它只是手段的选择。
- 我知道这一点,但由于有些项目是这样做的,而有些项目不是这样做的,所以我想知道,对于一个大型的Python项目,我应该采取哪一种方式——从长远来看,这个决定真的很重要吗?
- 就是这样-你选择哪一边并不重要,因为那里没有"对"的一面。这是一个完全主观的决定。
- 不比任何其他琐碎的决定更重要。en.wikipedia.org/wiki/parkinson's_law_of_琐碎
- 如果没有"python"命令,如何直接执行python文件?
- @禅宗假设你包括舍邦()!/usr/bin/env python)在脚本中,只需使脚本可执行即可。像chmod a+x [your-script].py这样的东西应该使它可执行,然后您可以在shell中调用./[your-script.py]。
- 正如glassghost给出的答案所指出的那样,除了味道之外,包含它还有一个具体的优势:它向未来的文件阅读器表明,他们正在读取一个可执行脚本,而不是一个要导入的文件。与拥有它们的语言中的公共/私有访问控制修饰符类似,shebang作为文档以及它们的实际效果都很有用,在某些情况下,文档方面实际上最重要。
- 这不是if __name__ =="__main__":的目的吗?
- 如果您将程序分发给不一定是程序员的其他人,那么最好使用shebang行,这样他们就可以透明地执行文件,从而了解python。
- 没有人提到过一个优点,如果在当前shell会话中有可用的路径中的脚本,您可以将它们作为可执行文件全局运行,这是一个相当好的优点imo,您甚至可以删除.py扩展名,没有人会知道您的可执行文件实际上是一个脚本。
- 我曾经这样做只是为了指示和有点强制我的脚本使用特定的Python版本。有整个2对3的混乱,一些新版本的3也有新的语法。
Should I put the shebang in my Python scripts?
在python脚本中放入shebang以指示:
- 此模块可以作为脚本运行
- 它是只能在python2、python3上运行,还是与python2/3兼容
- 在posix上,如果您希望直接运行脚本而不显式调用python可执行文件,则有必要
Are these equally portable? Which form is used most?
如果您手动编写shebang,那么一定要使用#!/usr/bin/env python,除非您有特定的理由不使用它。这种形式甚至在Windows(Python启动程序)上也可以理解。
注意:安装的脚本应该使用特定的python可执行文件,例如/usr/bin/python或/home/me/.virtualenvs/project/bin/python。如果在shell中激活一个virtualenv,那么一些工具损坏是很糟糕的。幸运的是,在大多数情况下,正确的shebang是由setuptools或分发包工具(在Windows上,setuptools可以自动生成包装.exe脚本)自动创建的。
换句话说,如果脚本在源代码签出中,那么您可能会看到#!/usr/bin/env python。如果安装了shebang,则shebang是指向特定python可执行文件(如#!/usr/local/bin/python)的路径(注意:不应手动写入后一类中的路径)。
要选择是否应在shebang中使用python、python2或python3,请参见pep 394-类Unix系统上的"python"命令:
-
... python should be used in the shebang line only for scripts that are
source compatible with both Python 2 and 3.
-
in preparation for an eventual change in the default version of
Python, Python 2 only scripts should either be updated to be source
compatible with Python 3 or else to use python2 in the shebang line.
- 即使提到政治公众人物的第一个答案也没有足够的赞成票。呵呵?是否有针对#!/usr/bin/env python本身的政治公众人物?
如果您有多个版本的python,并且脚本需要在特定的版本下运行,那么she-bang可以确保在直接执行脚本时使用正确的版本,例如:
注意,脚本仍然可以通过完整的python命令行运行,或者通过导入运行,在这种情况下,she-bang将被忽略。但是对于直接运行的脚本,这是使用she-bang的一个很好的理由。
#!/usr/bin/env python通常是更好的方法,但这对特殊情况有帮助。
通常,最好建立一个python虚拟环境,在这种情况下,通用的#!/usr/bin/env python将为virtualenv标识正确的python实例。
- 空间不会导致它失效吗?
- @随机化不,我不这么认为。空间似乎很常见,而且有很多证据表明这是一种公认的用法。然而,我认为没有空间可能是更规范的用法。
- 你绝对是对的。刚刚在bash和tcsh上测试过。
- which的结果将为您提供一个有效的字符串,句号。你用不着担心任何胆量。
如果脚本要可执行,则应添加shebang。您还应该使用一个安装软件来安装脚本,该软件将shebang修改为正确的版本,这样它就可以在目标平台上工作。例如distutils和distribute。
- 您不必修改!之后排队。这就是/usr/bin/env的目的。针对特定的Python解释器进行硬编码可能弊大于利。对于安装另一个python版本或在发行版的python与定制的python安装之间切换,这是非常脆弱的。
- 在Ubuntu中,使用which的结果将自动选择系统命令等使用的默认值。它是通用的,系统引导它正确安装。
shebang的目的是让脚本在您想从shell执行脚本时识别解释器类型。大多数情况下,也不总是通过外部提供解释器来执行脚本。示例用法:python-x.x script.py。
即使没有shebang声明器,这也可以工作。
第一个更"可移植"的原因是,/usr/bin/env包含了您的PATH声明,它说明了您的系统可执行文件所在的所有目的地。
注意:Tornado不严格使用shebangs,django严格不使用shebangs。它随应用程序的主要功能的执行方式而变化。
另外:它不会随python而变化。
有时,如果答案不是很清楚(我的意思是你不能决定是或否),那么它并不重要太多,你可以忽略问题,直到答案清楚为止。
#!的唯一目的是启动脚本。Django自己加载源并使用它们。它从不需要决定应该使用什么样的解释程序。这样一来,#!在这里就毫无意义了。
一般来说,如果它是一个模块,不能用作脚本,就不需要使用#!。另一方面,模块源通常包含if __name__ == '__main__': ...,至少对功能进行一些简单的测试。然后,#!又有了意义。
使用#!的一个很好的原因是当您同时使用python 2和python 3脚本时——它们必须由不同版本的python解释。这样,您就必须记住在手动启动脚本时(在不使用#!的情况下)必须使用哪些python。如果您混合使用这些脚本,最好在内部使用#!,使它们可执行,并将它们作为可执行文件(chmod…)启动。
当使用MS Windows时,#!直到最近才有意义。python 3.3引入了一个windows python启动程序(py.exe和pyw.exe),它读取#!行,检测安装的python版本,并使用正确或明确需要的python版本。由于扩展可以与程序关联,因此在Windows中可以获得与基于Unix的系统中的Execute标志相似的行为。
当我最近在Windows7上安装了python 3.6.1时,它还安装了用于windows的python launcher for windows,它应该处理shebang行。但是,我发现python启动程序并没有这样做:shebang行被忽略,并且总是使用python 2.7.13(除非我使用py-3执行脚本)。
为了解决这个问题,我必须编辑Windows注册表项HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Python.File\shell\open\command。这仍然有价值
1
| "C:\Python27\python.exe""%1" %* |
从我以前的python 2.7安装。我将此注册表项值修改为
1
| "C:\Windows\py.exe""%1" %* |
而python启动程序shebang行的处理工作如上所述。
答:只有当您计划将其设置为命令行可执行脚本时。程序如下:
首先验证要使用的正确shebang字符串:
从中获取输出并添加它(使用shebang!)在第一行。
在我的系统上,它的响应如下:
1 2
| $which python
/usr/bin/python |
所以你的shebang看起来像:
保存之后,它仍将像以前一样运行,因为Python将第一行视为注释。
要使其成为命令,请复制它以删除.py扩展名。
告诉文件系统这将是可执行的:
要测试它,请使用:
最佳实践是将其移动到$path中的某个位置,这样您只需要键入文件名本身。
1
| sudo cp filename /usr/sbin |
这样它就可以在任何地方工作(在文件名之前没有./
首先使用
这将提供输出作为我的Python解释器(二进制)所在的位置。
这个输出可以是
或
现在适当地选择shebang线并使用它。
概括起来,我们可以使用:
或
- 这很可能无法移植到其他系统。#!/usr/bin/env为您做出了正确的选择。
- 这就是为什么您使用which命令-它将为您的特定系统返回正确的字符串。
- …然后每次在另一台机器上执行脚本时,都会再次运行which python,如果输出与当前shebang不同,则更改脚本。
- 是否需要根据您的评论进行编辑…
- -这是最脆弱的解决方案。它只保证对于编写Python脚本的系统是正确的。用!/usr/bin/env python3便于携带