Re: Mercurial 0.4b vs git patchbomb benchmark

>> > That said, I think the /usr/bin/env trick is stupid too. It may be more
>> > portable for various Linux distributions, but if you want _true_
>> > portability, you use /bin/sh, and you do something like
>> > 
>> > #!/bin/sh
>> > exec perl perlscript.pl "$@"
>> if 0;

> Linus Torvalds <torvalds@osdl.org> wrote:
> > On Mon, 2 May 2005, Ryan Anderson wrote:
> >> On Mon, May 02, 2005 at 09:31:06AM -0700, Linus Torvalds wrote:
> 
> >> > That said, I think the /usr/bin/env trick is stupid too. It may be more
> >> > portable for various Linux distributions, but if you want _true_
> >> > portability, you use /bin/sh, and you do something like
> >> > 
> >> > #!/bin/sh
> >> > exec perl perlscript.pl "$@"
> >> if 0;
> 
> exec may fail.
> 
> #!/bin/sh
> exec perl -x $0 ${1+"$@"} || exit 127
> #!perl
> 
> >> You don't really want Perl to get itself into an exec loop.
> > 
> > This would _not_ be "perlscript.pl" itself. This is the shell-script, and
> > it's not called ".pl".
> 
> In this thread, it originally was.

> On Tue, May 03, 2005 at 03:16:26AM +0200, Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org> wrote:
> 
>>Linus Torvalds <torvalds@osdl.org> wrote:
>>
>>>On Mon, 2 May 2005, Ryan Anderson wrote:
>>>
>>>>On Mon, May 02, 2005 at 09:31:06AM -0700, Linus Torvalds wrote:
>>
>>>>>That said, I think the /usr/bin/env trick is stupid too. It may be more
>>>>>portable for various Linux distributions, but if you want _true_
>>>>>portability, you use /bin/sh, and you do something like
>>>>>
>>>>>#!/bin/sh
>>>>>exec perl perlscript.pl "$@"
>>>>
>>>>if 0;
>>
>>exec may fail.
>>
>>#!/bin/sh
>>exec perl -x $0 ${1+"$@"} || exit 127
>>#!perl
>>
>>
>>>>You don't really want Perl to get itself into an exec loop.
>>>
>>>This would _not_ be "perlscript.pl" itself. This is the shell-script, and
>>>it's not called ".pl".
>>
>>In this thread, it originally was.
> 
> 
> In this thread, it was originally a Python script. In particular, one
> aimed at managing the Linux kernel source. I'm going to use
> /usr/bin/env, systems where that doesn't exist can edit the source.

> 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"'

> 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. :]