Why do people write #!/usr/bin/env python on the first line of a Python script? – Dev

The best answers to the question “Why do people write #!/usr/bin/env python on the first line of a Python script?” in the category Dev.


I see this at the top of Python files:

  1. For Python 2 files
    #!/usr/bin/env python
  2. For Python 3 files
    #!/usr/bin/env python3

It seems to me like the files run the same without that line.


That is called the shebang line. As the Wikipedia entry explains:

In computing, a shebang (also called a hashbang, hashpling, pound bang, or crunchbang) refers to the characters “#!” when they are the first two characters in an interpreter directive as the first line of a text file. In a Unix-like operating system, the program loader takes the presence of these two characters as an indication that the file is a script, and tries to execute that script using the interpreter specified by the rest of the first line in the file.

See also the Unix FAQ entry.

Even on Windows, where the shebang line does not determine the interpreter to be run, you can pass options to the interpreter by specifying them on the shebang line. I find it useful to keep a generic shebang line in one-off scripts (such as the ones I write when answering questions on SO), so I can quickly test them on both Windows and ArchLinux.

The env utility allows you to invoke a command on the path:

The first remaining argument specifies the program name to invoke; it is searched for according to the PATH environment variable. Any remaining arguments are passed as arguments to that program.


If you have several versions of Python installed, /usr/bin/env will ensure the interpreter used is the first one on your environment’s $PATH. The alternative would be to hardcode something like #!/usr/bin/python; that’s ok, but less flexible.

In Unix, an executable file that’s meant to be interpreted can indicate what interpreter to use by having a #! at the start of the first line, followed by the interpreter (and any flags it may need).

If you’re talking about other platforms, of course, this rule does not apply (but that “shebang line” does no harm, and will help if you ever copy that script to a platform with a Unix base, such as Linux, Mac, etc).


In order to run the python script, we need to tell the shell three things:

  1. That the file is a script
  2. Which interpreter we want to execute the script
  3. The path of said interpreter

The shebang #! accomplishes (1.). The shebang begins with a # because the # character is a comment marker in many scripting languages. The contents of the shebang line are therefore automatically ignored by the interpreter.

The env command accomplishes (2.) and (3.). To quote “grawity,”

A common use of the env command is to launch interpreters, by making
use of the fact that env will search $PATH for the command it is told
to launch. Since the shebang line requires an absolute path to be
specified, and since the location of various interpreters (perl, bash,
python) may vary a lot, it is common to use:

#!/usr/bin/env perl  instead of trying to guess whether it is
/bin/perl, /usr/bin/perl, /usr/local/bin/perl, /usr/local/pkg/perl,
/fileserver/usr/bin/perl, or /home/MrDaniel/usr/bin/perl on the user’s

On the other hand, env is almost always in /usr/bin/env. (Except in
cases when it isn’t; some systems might use /bin/env, but that’s a
fairly rare occassion and only happens on non-Linux systems.)


Expanding a bit on the other answers, here’s a little example of how your command line scripts can get into trouble by incautious use of /usr/bin/env shebang lines:

$ /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

The json module doesn’t exist in Python 2.5.

One way to guard against that kind of problem is to use the versioned python command names that are typically installed with most Pythons:

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

If you just need to distinguish between Python 2.x and Python 3.x, recent releases of Python 3 also provide a python3 name:

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