The typical header should be
But I found below also works when executing the script like
What’s difference between these 2 headers? What could be the problem for 2nd one? Please also discussing the case for python interpreter is in PATH or not. Thanks.
First, any time you run a script using the interpreter explicitly, as in
$ python ./my_script.py $ ksh ~/bin/redouble.sh $ lua5.1 /usr/local/bin/osbf3
#! line is always ignored. The
#! line is a Unix feature of executable scripts only, and you can see it documented in full on the man page for
execve(2). There you will find that the word following
#! must be the pathname of a valid executable. So
python is on the users
$PATH. This form is resilient to the Python interpreter being moved around, which makes it somewhat more portable, but it also means that the user can override the standard Python interpreter by putting something ahead of it in
$PATH. Depending on your goals, this behavior may or may not be OK.
deals with the common case that a Python interpreter is installed in
/usr/bin. If it’s installed somewhere else, you lose. But this is a good way to ensure you get exactly the version you want or else nothing at all (“fail-stop” behavior), as in
works only if there is a
python executable in the current directory when the script is run. Not recommended.
I’d suggest 3 things in the beginning of your script:
First, as already being said use environment:
Second, set your encoding:
# -*- coding: utf-8 -*-
Third, set some doc string:
"""This is a awesome python script!"""
And for sure I would use
" " (4 spaces) for ident.
Final header will look like:
#!/usr/bin/env python # -*- coding: utf-8 -*- """This is a awesome python script!"""
Best wishes and happy coding.
The Python executable might be installed at a location other than /usr/bin, but
env is nearly always present in that location so using
/usr/bin/envis more portable.
From the manpage for
env (GNU coreutils 6.10):
env - run a program in a modified environment
In theory you could use
env to reset the environment (removing many of the existing environment variables) or add additional environment variables in the script header. Practically speaking, the two versions you mentioned are identical. (Though others have mentioned a good point: specifying
env lets you abstractly specify
python without knowing its path.)
Yes, there is – python may not be in
/usr/bin, but for example in
When using virtualenv, it may even be something like
/usr/bin/env python becomes very useful when your scripts depend on environment settings for example using scripts which rely on
python virtualenv. Each virtualenv has its own version of python binary which is required for adding packages installed in virtualenv to python path (without touching PYTHONPATH env).
As more and more people have started to used virtualenv for python development prefer to use
/usr/bin/env python unless you don’t want people to use their custom python binary.
Note: You should also understand that there are potential security issues (in multiuser environments) when you let people run your scripts in their custom environments. You can get some ideas from here.