Re: Mercurial 0.4b vs git patchbomb benchmark

From: Bill Davidsen <davidsen@tmr.com>
Date: May 4, 2005, 17:51 UTC
Message-ID: <42790B8A.9010406@tmr.com>
In-Reply-To: <4277B15F.1020102@lsrfire.ath.cx>

Rene Scharfe wrote:

Show 29 quoted lines

> Bill Davidsen schrieb:
> 
>>On the theory that my first post got lost, why use /usr/bin/env at 
>>all, when bash already does that substitution? To support people who 
>>use other shells?
>>
>>ie.: FOO=xx perl -e '$a=$ENV{FOO}; print "$a\n"'
> 
> 
> /usr/bin/env is used in scripts in the shebang line (the very first line
> of the script, starting with "#!", which denotes the interpreter to use
> for that script) to make a PATH search for the real interpreter.
> Some folks keep their python (or Perl, or Bash etc.) in /usr/local/bin
> or in $HOME, that's why this construct is needed at all.
> 
> Changing environment variables is not the goal, insofar this usage
> exploits only a side-effect of env.  It is portable in practice because
> env is in /usr/bin on most modern systems.
> 
> So you could replace this first line of a bash script:
> 
>    #!/usr/bin/env python
> 
> with this:
> 
>    #!python
> 
> except that the latter doesn't work because you need to specify an
> absolute path there. :]

Assuming that you want the PATH search rather than a symlink in /usr/bin, of course. This opens the door to forgetting you just loaded the CVS daily of python into your test directory and doing an unplanned test of alpha software, but if people think the application should work with non-standard tool chains, and realize it has possible unwanted effects, that's a design decision.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me