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

[Ben Finney]

Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> writes:

> -On [20080502 07:51], Ben Finney (bignose+hates-spam at benfinney.id.au) wrote:
> >To my mind, the Python interpreter installed by a package as
> >distributed with the OS *is* OS territory and belongs in /usr/bin/.
> 
> That's the difference with a distribution, such as Linux, and full
> OSes , such as BSDs or commercial Unix variants. They prefer to keep
> a pristine state for the OS vendor files versus what the user can
> opt to install himself, hence the /usr/bin - /usr/local/bin
> separation.

Fine so far. /usr/local/ is certainly for "what the (system
administrator) user opts to install themselves".

> It effectively guarantees you can nuke /usr/local without ill
> consequences for your OS.

You say this as though it's a property that a GNU/Linux distribution
doesn't have. But the "keep /usr/local/ untouched by OS packages"
approach taken by GNU/Linux *also* means that /usr/local/ can be blown
away without ill consequences for the OS. So I don't see why you draw
that distinction here.

The difference seems to be that Python is an OS-installable package on
GNU/Linux, and thus gets installed to the OS-packaged location. So the
default Python installation should work.

Whereas if Python is *not* installed from an OS package, it's up to
the sys admin to ensure that it works -- not up to my program. So I
don't see the point in making it work by default, when what I want for
my program is that it works *with the default Python*, not with some
non-default installation.

-- 
 \       "Truth is stranger than fiction, but it is because fiction is |
  `\         obliged to stick to possibilities, truth isn't."  -- Mark |
_o__)                                   Twain, _Following the Equator_ |
Ben Finney