#!/usr/bin/env python vs. #!/usr/bin/python

[andrej.panjkov]

At our site we run IRIX, UNICOS, Solaris, Tru64, Linux, cygwin and
other unixy OSes.

We have python installed in a number of different places:
/bin/python
/usr/local/bin/python
/usr/bin/python
/opt/freeware/Python/Python-2.5.1/bin/python
~mataap/platform/python/python-2.5.1

So I cannot assume a single location for python. Nor for any other
tool, really. Bash for example. It may indeed be in /usr/bin on many
systems, on many others it is not.

Note the version specific install points. This allows us to switch
over easily to different versions, and keep older versions in case
they are needed. We can test new versions before cutting over to them
operationally. (This matters for tools that are still changing, like
python or bash.)

We use the very handy 'modules' package (not python modules, not
fortran modules) to adjust our paths and environment variables as
needed.

Some of the install points are determined by policy, or historical
constraints, or hardware limits, or file system layout.

Now it is true that it is easy to edit a single script to change the
hashbang line. It is not easy to change several hundred scripts, on
different machines. It is easy to adjust the environment to point to
the right python path, and have all your scripts pick it up
automatically.

Use /usr/bin/env. If env is not in /usr/bin, put a link to it there.

 

[Banibrata Dutta]

At our site we run IRIX, UNICOS, Solaris, Tru64, Linux, cygwin and
other unixy OSes.

We have python installed in a number of different places:
/bin/python
/usr/local/bin/python
/usr/bin/python
/opt/freeware/Python/Python-2.5.1/bin/python
~mataap/platform/python/python-2.5.1

So I cannot assume a single location for python. Nor for any other
tool, really. Bash for example. It may indeed be in /usr/bin on many
systems, on many others it is not.

Note the version specific install points. This allows us to switch
over easily to different versions, and keep older versions in case
they are needed. We can test new versions before cutting over to them
operationally. (This matters for tools that are still changing, like
python or bash.)

We use the very handy 'modules' package (not python modules, not
fortran modules) to adjust our paths and environment variables as
needed.

Some of the install points are determined by policy, or historical
constraints, or hardware limits, or file system layout.

Now it is true that it is easy to edit a single script to change the
hashbang line. It is not easy to change several hundred scripts, on
different machines. It is easy to adjust the environment to point to
the right python path, and have all your scripts pick it up
automatically.

Looks reasonable thing to do...

Use /usr/bin/env. If env is not in /usr/bin, put a link to it there.

So why not put symlink to Python over there on all machines, if we can
put one (or env itself) there ?

 

[Wojciech Walczak]

So why not put symlink to Python over there on all machines, if we can
put one (or env itself) there ?

To avoid linking all the rest of interpreters like perl, ruby, lua and dozens
of others.

 

[andrej.panjkov]

The argument was being made from "thousands of scripts". Isn't "dozens
of symlinks" better?

It depends on single user vs multi user. We keep multiple versions of
packages because some software requires the older versions. Which
version do we symlink to? What if we simultaneously require access to
two different versions? For example, to keep legacy software going,
or to test updated versions while keeping operational versions
running.
What if we have shared file systems, and we have multiplatform
versions? Python for solaris, python for tru64?

In a sense, we do have dozens of "virtual" links, using the modules
package to adjust paths on the fly. This is more flexible than having
a static symlink in /usr/bin. It allows us to select on a per user,
per process, per script basis, the python we want, version, platform
etc. With a static symlink, every user/process/job gets the same
python, unless you want to flip symlinks around.

Also, every 10 years or so, each platform gets replaced, so we are
replacing platforms here every few years. And we don't always get the
same replacement system. Sure we can go in and touch up all the
scripts. But it just seems so much easier and flexible to tell a
python/bash/other script to use what you get from the path, and set
the paths.

Of course, things are different on a single user desktop system, with
its own filesystems. If you are sure where python is, and you only
have one python, and you don't mind revisiting your scripts and
editing them if things change, by all means hard code the python path
in.

A

 

[Brian Vanderburg II]

This is sort of related, but I'm wondering what is different between
"#!/usr/bin/env python" and "#!python". Wouldn't the second do the same
thing, since an absolute path is not specified, find 'python' from the
PATH environment, I don't really know.

Brian Vanderburg II

 

[D'Arcy J.M. Cain]

This is sort of related, but I'm wondering what is different between
"#!/usr/bin/env python" and "#!python". Wouldn't the second do the same
thing, since an absolute path is not specified, find 'python' from the
PATH environment, I don't really know.

Well, I know what happened when I tried it. What happened when you
tried it?

 

[Brian Vanderburg II]

Well, I know what happened when I tried it. What happened when you
tried it?

I haven't tried it but I've seen some files like written that in the
past with just a name and no path for some other interpreter (perl or sh
probably) and didn't know what the different was or if it was even
valid. I at a windows system now so I can't try it yet.

Brian Vanderburg II

 

[Tim Roberts]

I haven't tried it but I've seen some files like written that in the
past with just a name and no path for some other interpreter (perl or sh
probably) and didn't know what the different was or if it was even
valid.

It's not valid. The shebang line (#!) must specify a full path. When you
saw the lone word ("perl"), it was probably a /usr/bin/env line, just we
have been discussing.

I at a windows system now so I can't try it yet.

*IF* you are interested in playing with Linux, most of the distributions
have bootable CDs that will bring up a full Linux environment without ever
touching your hard disk.