Messages in this thread | | | Date | Tue, 03 May 2005 12:22:06 -0400 | From | Bill Davidsen <> | Subject | Re: Mercurial 0.4b vs git patchbomb benchmark |
| |
Matt Mackall wrote: > 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 (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |