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

[andrej.panjkov at climatechange.qld.gov.au]

On May 6, 9:06 pm, Ben Finney <bignose+hates-s... at benfinney.id.au>
wrote:
> "Wojciech Walczak" <wojtek.gminick.walc... at gmail.com> writes:
> > 2008/5/6, Banibrata Dutta <banibrata.du... at gmail.com>:
> > >  > 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 ?
>
> > To avoid linking all the rest of interpreters like perl, ruby, lua
> > and dozens of others.
>
> 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