# Re: Mercurial 0.4b vs git patchbomb benchmark 5 messages from 2005-05-03 to 2005-05-04. Participants: Bodo Eggert , Matt Mackall, Bill Davidsen, Rene Scharfe. Thread: https://gitlist.dev/t/449 ## Bodo Eggert , 2005-05-03 01:16 Subject: Re: Mercurial 0.4b vs git patchbomb benchmark Message-ID: URL: https://gitlist.dev/e/E1DSm1T-0002Tc-FV%40be1.7eggert.dyndns.org In-Reply-To: <3ZNdz-6gK-9@gated-at.bofh.it> ``` Linus Torvalds 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. -- "Our parents, worse than our grandparents, gave birth to us who are worse than they, and we shall in our turn bear offspring still more evil." -- Horace (BC 65-8) ``` ## Matt Mackall, 2005-05-03 01:29 Subject: Re: Mercurial 0.4b vs git patchbomb benchmark Message-ID: <20050503012921.GD22038@waste.org> URL: https://gitlist.dev/e/20050503012921.GD22038%40waste.org In-Reply-To: ``` On Tue, May 03, 2005 at 03:16:26AM +0200, Bodo Eggert wrote: > Linus Torvalds 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. -- Mathematics is the supreme nostalgia of our time. ``` ## Bill Davidsen, 2005-05-03 16:22 Subject: Re: Mercurial 0.4b vs git patchbomb benchmark Message-ID: <4277A52E.1020601@tmr.com> URL: https://gitlist.dev/e/4277A52E.1020601%40tmr.com In-Reply-To: <20050503012921.GD22038@waste.org> ``` Matt Mackall wrote: > On Tue, May 03, 2005 at 03:16:26AM +0200, Bodo Eggert wrote: > >>Linus Torvalds 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 (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me ``` ## Rene Scharfe, 2005-05-03 17:14 Subject: Re: Mercurial 0.4b vs git patchbomb benchmark Message-ID: <4277B15F.1020102@lsrfire.ath.cx> URL: https://gitlist.dev/e/4277B15F.1020102%40lsrfire.ath.cx In-Reply-To: <4277A52E.1020601@tmr.com> ``` 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. :] Rene ``` ## Bill Davidsen, 2005-05-04 17:51 Subject: Re: Mercurial 0.4b vs git patchbomb benchmark Message-ID: <42790B8A.9010406@tmr.com> URL: https://gitlist.dev/e/42790B8A.9010406%40tmr.com In-Reply-To: <4277B15F.1020102@lsrfire.ath.cx> ``` Rene Scharfe wrote: > 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 ```