Why do people write #!/usr/bin/env python on the first line of a Python script?
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 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
PATHenvironment variable. Any remaining arguments are passed as arguments to that program.
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 -VPython 2.6.4$ /usr/bin/python -VPython 2.5.1$ cat my_script.py #!/usr/bin/env pythonimport jsonprint "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 jsonImportError: 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.6import jsonprint "hello, json"
If you just need to distinguish between Python 2.x and Python 3.x, recent releases of Python 3 also provide a
$ cat my_script.py #!/usr/bin/env python3import jsonprint("hello, json")