＃！/ usr / bin / python和＃！/ usr / bin / env python，哪个支持？

Question

How should the shebang for a Python script look like?

Some people support #!/usr/bin/env python because it can find the Python interpreter intelligently. Others support #!/usr/bin/python , because now in most GNU/Linux distributions python is the default program.

What are the benefits of the two variants?

Answer 1

The Debian Python Policy states:

The preferred specification for the Python interpreter is /usr/bin/python or /usr/bin/pythonX.Y . This ensures that a Debian installation of python is used and all dependencies on additional python modules are met.

Maintainers should not override the Debian Python interpreter using /usr/bin/env python or /usr/bin/env pythonX.Y . This is not advisable as it bypasses Debian's dependency checking and makes the package vulnerable to incomplete local installations of python.

Note that Debian/Ubuntu use the alternatives system to manage which version /usr/bin/python actually points to. This has been working very nicely across a lot of python versions at least for me (and I've been using python from 2.3 to 2.7 now), with excellent transitions across updates.

Note that I've never used pip . I want automatic security upgrades, so I install all my python needs via aptitude . Using the official Debian/Ubuntu packages keep my system much cleaner than me messing around with the python installation myself.

---

Let me emphasize one thing. The above recommendation refers to system installation of python applications. It makes perfectly sense to have these use the system managed version of python. If you are actually playing around with your own, customized installation of python that is not managed by the operating system, using the env variant probably is the correct way of saying "use the user-preferred python", instead of hard-coding either the system python installation (which would be /usr/bin/python ) or any user-custom path.

Using env python will cause your programs to behave differently if you call them from eg a python virtualenv.

This can be desired (eg you are writing a script to work only in your virtualenv). And it can be problematic (you write a tool for you, and expect it to work the same even within a virtualenv - it may suddenly fail because it is missing packages then).

Answer 2

My humble opinion is that you should use the env -variant. It's a POSIX component thus found in pretty much every system, while directly specifying /usr/bin/python breaks in many occasions, ie virtualenv setups.

Answer 3

I use #!/usr/bin/env python as the default install location on OS-X is NOT /usr/bin . This also applies to users who like to customize their environment -- /usr/local/bin is another common place where you might find a python distribution.

That said, it really doesn't matter too much. You can always test the script with whatever python version you want: /usr/bin/strange/path/python myscript.py . Also, when you install a script via setuptools, the shebang seems to get replaced by the sys.executable which installed that script -- I don't know about pip , but I would assume it behaves similarly.

Answer 4

As you note, they probably both work on linux. However, if someone has installed a newer version of python for their own use, or some requirement makes people keep a particular version in /usr/bin, the env allows the caller to set up their environment so that a different version will be called through env.

Imagine someone trying to see if python 3 works with the scripts. They'll add the python3 interpreter first in their path, but want to keep the default on the system running on 2.x. With a hardcoded path that's not possible.