Re: Mercurial 0.4b vs git patchbomb benchmark (/usr/bin/env again)

["David A. Wheeler" <dwheeler@dwheeler.com>]

Valdis.Kletnieks@vt.edu wrote:
>> Most likely, his python lives elsewhere than /usr/bin, and the 'env' call
>> results in causing a walk across $PATH to find it....

Bill Davidsen wrote:
> Assuming that he has env in a standard place... I hope this isn't going 
> to start some rash of efforts to make packages run on non-standard 
> toolchains, which add requirements for one tool to get around 
> misplacement of another.

The #!/usr/bin/env prefix is, in my opinion, a very good idea.
There are a very few systems where env isn't in /usr/bin, but they
were extremely rare years ago & are essentially extinct now.
Basically, it's a 99% solution; getting the last 1% is really painful,
but since getting the 99% is easy, let's do it and be happy.

There are LOTS of systems where Python, bash, etc., do NOT
live in whatever place you think of as "standard".
I routinely use an OpenBSD 3.1 system; there is no /usr/bin/bash,
but there _IS_ a /usr/local/bin/bash (in my PATH) and a /usr/bin/env.
So this /usr/bin/env stuff REALLY is useful on a lot of systems, such
as OpenBSD.  It's critical to me, at least!

This is actually really useful on ANY system, though.
Even if some interpreter IS where you think it should be,
that is NOT necessarily the interpreter you want to use.
Using "/usr/bin/env" lets you use PATH
to override things, so you don't HAVE to use the interpreter
in some fixed location.  That's REALLY handy for testing... I
can download the whizbang Python 9.8.2, set it on the path,
and see if everything works as expected.  It's also nice
if someone insists on never upgrading a package; you can
install an interpreter "locally".  Yes, you can patch all the
files up, but resetting a PATH is _much_ easier.

--- David A. Wheeler