It seems to me like the files run the same without that line.
It seems to me like the files run the same without that line.
If so, then perhaps you're running the Python program on Windows? Windows doesn't use that line—instead, it uses the file-name extension to run the program associated with the file extension.
However in 2011, a "Python launcher" was developed which (to some degree) mimics this Linux behaviour for Windows. This is limited just to choosing which Python interpreter is run — e.g. to select between Python 2 and Python 3 on a system where both are installed. The launcher is optionally installed as py.exe
by Python installation, and can be associated with .py
files so that the launcher will check that line and in turn launch the specified Python interpreter version.
This is meant as more of historical information than a "real" answer.
Remember that back in the day you had LOTS of unix like operating systems whose designers all had their own notion of where to put stuff, and sometimes didn't include Python, Perl, Bash, or lots of other GNU/Open Source stuff at all.
This was even true of different Linux distributions. On Linux--pre-FHS[1]-you might have python in /usr/bin/ or /usr/local/bin/. Or it might not have been installed, so you built your own and put it in ~/bin
Solaris was the worst I ever worked on, partially as the transition from Berkeley Unix to System V. You could wind up with stuff in /usr/, /usr/local/, /usr/ucb, /opt/ etc. This could make for some really long paths. I have memories of the stuff from Sunfreeware.com installing each package in it's own directory, but I can't recall if it symlinked the binaries into /usr/bin or not.
Oh, and sometimes /usr/bin was on an NFS server[2].
So the env
utility was developed to work around this.
Then you could write #!/bin/env interpreter
and as long as the path was proper things had a reasonable chance of running. Of course, reasonable meant (for Python and Perl) that you had also set the appropriate environmental variables. For bash/ksh/zsh it just worked.
This was important because people were passing around shell scripts (like perl and python) and if you'd hard coded /usr/bin/python on your Red Hat Linux workstation it was going to break bad on a SGI...well, no, I think IRIX put python in the right spot. But on a Sparc station it might not run at all.
I miss my sparc station. But not a lot. Ok, now you've got me trolling around on E-Bay. Bastages.
[1] File-system Hierarchy Standard. https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
[2] Yes, and sometimes people still do stuff like that. And no, I did not wear either a turnip OR an onion on my belt.
The main reason to do this is to make the script portable across operating system environments.
For example under mingw, python scripts use :
#!/c/python3k/python
and under GNU/Linux distribution it is either:
#!/usr/local/bin/python
or
#!/usr/bin/python
and under the best commercial Unix sw/hw system of all (OS/X), it is:
#!/Applications/MacPython 2.5/python
or on FreeBSD:
#!/usr/local/bin/python
However all these differences can make the script portable across all by using:
#!/usr/bin/env python
this tells the script where is python directory !
#! /usr/bin/env python
Perhaps your question is in this sense:
If you want to use: $python myscript.py
You don't need that line at all. The system will call python and then python interpreter will run your script.
But if you intend to use: $./myscript.py
Calling it directly like a normal program or bash script, you need write that line to specify to the system which program use to run it, (and also make it executable with chmod 755
)
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).