{"thread":{"id":"449","subject":"Re: Mercurial 0.4b vs git patchbomb benchmark","startedAt":"2005-05-03T01:16:26Z","lastAt":"2005-05-04T17:51:06Z","messageCount":5,"participants":["Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>","Matt Mackall","Bill Davidsen","Rene Scharfe"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"2427","messageId":"E1DSm1T-0002Tc-FV@be1.7eggert.dyndns.org","threadId":"449","inReplyTo":"3ZNdz-6gK-9@gated-at.bofh.it","subject":"Re: Mercurial 0.4b vs git patchbomb benchmark","fromName":"Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>","fromEmail":"7eggert@gmx.de","sentAt":"2005-05-03T01:16:26Z","receivedAt":"2005-05-03T01:16:26Z","isPatch":false,"sender":{"key":"7eggert@gmx.de","avatar":"https://gravatar.com/avatar/9a1c1647bae71e0616fd65aef20206af544236fff9df4648647acf7a51517dac?d=mp&s=160"},"body":"Linus Torvalds <torvalds@osdl.org> wrote:\n> On Mon, 2 May 2005, Ryan Anderson wrote:\n>> On Mon, May 02, 2005 at 09:31:06AM -0700, Linus Torvalds wrote:\n\n>> > That said, I think the /usr/bin/env trick is stupid too. It may be more\n>> > portable for various Linux distributions, but if you want _true_\n>> > portability, you use /bin/sh, and you do something like\n>> > \n>> > #!/bin/sh\n>> > exec perl perlscript.pl \"$@\"\n>> if 0;\n\nexec may fail.\n\n#!/bin/sh\nexec perl -x $0 ${1+\"$@\"} || exit 127\n#!perl\n\n>> You don't really want Perl to get itself into an exec loop.\n> \n> This would _not_ be \"perlscript.pl\" itself. This is the shell-script, and\n> it's not called \".pl\".\n\nIn this thread, it originally was.\n-- \n\n\"Our parents, worse than our grandparents, gave birth to us who are worse than\nthey, and we shall in our turn bear offspring still more evil.\"\n        -- Horace (BC 65-8)\n\n"},{"id":"2428","messageId":"20050503012921.GD22038@waste.org","threadId":"449","inReplyTo":"E1DSm1T-0002Tc-FV@be1.7eggert.dyndns.org","subject":"Re: Mercurial 0.4b vs git patchbomb benchmark","fromName":"Matt Mackall","fromEmail":"mpm@selenic.com","sentAt":"2005-05-03T01:29:21Z","receivedAt":"2005-05-03T01:29:21Z","isPatch":false,"sender":{"key":"mpm@selenic.com","avatar":null},"body":"On Tue, May 03, 2005 at 03:16:26AM +0200, Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org> wrote:\n> Linus Torvalds <torvalds@osdl.org> wrote:\n> > On Mon, 2 May 2005, Ryan Anderson wrote:\n> >> On Mon, May 02, 2005 at 09:31:06AM -0700, Linus Torvalds wrote:\n> \n> >> > That said, I think the /usr/bin/env trick is stupid too. It may be more\n> >> > portable for various Linux distributions, but if you want _true_\n> >> > portability, you use /bin/sh, and you do something like\n> >> > \n> >> > #!/bin/sh\n> >> > exec perl perlscript.pl \"$@\"\n> >> if 0;\n> \n> exec may fail.\n> \n> #!/bin/sh\n> exec perl -x $0 ${1+\"$@\"} || exit 127\n> #!perl\n> \n> >> You don't really want Perl to get itself into an exec loop.\n> > \n> > This would _not_ be \"perlscript.pl\" itself. This is the shell-script, and\n> > it's not called \".pl\".\n> \n> In this thread, it originally was.\n\nIn this thread, it was originally a Python script. In particular, one\naimed at managing the Linux kernel source. I'm going to use\n/usr/bin/env, systems where that doesn't exist can edit the source.\n\n--\nMathematics is the supreme nostalgia of our time.\n"},{"id":"2482","messageId":"4277A52E.1020601@tmr.com","threadId":"449","inReplyTo":"20050503012921.GD22038@waste.org","subject":"Re: Mercurial 0.4b vs git patchbomb benchmark","fromName":"Bill Davidsen","fromEmail":"davidsen@tmr.com","sentAt":"2005-05-03T16:22:06Z","receivedAt":"2005-05-03T16:22:06Z","isPatch":false,"sender":{"key":"davidsen@tmr.com","avatar":null},"body":"Matt Mackall wrote:\n> On Tue, May 03, 2005 at 03:16:26AM +0200, Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org> wrote:\n> \n>>Linus Torvalds <torvalds@osdl.org> wrote:\n>>\n>>>On Mon, 2 May 2005, Ryan Anderson wrote:\n>>>\n>>>>On Mon, May 02, 2005 at 09:31:06AM -0700, Linus Torvalds wrote:\n>>\n>>>>>That said, I think the /usr/bin/env trick is stupid too. It may be more\n>>>>>portable for various Linux distributions, but if you want _true_\n>>>>>portability, you use /bin/sh, and you do something like\n>>>>>\n>>>>>#!/bin/sh\n>>>>>exec perl perlscript.pl \"$@\"\n>>>>\n>>>>if 0;\n>>\n>>exec may fail.\n>>\n>>#!/bin/sh\n>>exec perl -x $0 ${1+\"$@\"} || exit 127\n>>#!perl\n>>\n>>\n>>>>You don't really want Perl to get itself into an exec loop.\n>>>\n>>>This would _not_ be \"perlscript.pl\" itself. This is the shell-script, and\n>>>it's not called \".pl\".\n>>\n>>In this thread, it originally was.\n> \n> \n> In this thread, it was originally a Python script. In particular, one\n> aimed at managing the Linux kernel source. I'm going to use\n> /usr/bin/env, systems where that doesn't exist can edit the source.\n\nOn the theory that my first post got lost, why use /usr/bin/env at all, \nwhen bash already does that substitution? To support people who use \nother shells?\n\nie.:\n    FOO=xx perl -e '$a=$ENV{FOO}; print \"$a\\n\"'\n-- \n    -bill davidsen (davidsen@tmr.com)\n\"The secret to procrastination is to put things off until the\n  last possible moment - but no longer\"  -me\n"},{"id":"2487","messageId":"4277B15F.1020102@lsrfire.ath.cx","threadId":"449","inReplyTo":"4277A52E.1020601@tmr.com","subject":"Re: Mercurial 0.4b vs git patchbomb benchmark","fromName":"Rene Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2005-05-03T17:14:07Z","receivedAt":"2005-05-03T17:14:07Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Bill Davidsen schrieb:\n> On the theory that my first post got lost, why use /usr/bin/env at \n> all, when bash already does that substitution? To support people who \n> use other shells?\n> \n> ie.: FOO=xx perl -e '$a=$ENV{FOO}; print \"$a\\n\"'\n\n/usr/bin/env is used in scripts in the shebang line (the very first line\nof the script, starting with \"#!\", which denotes the interpreter to use\nfor that script) to make a PATH search for the real interpreter.\nSome folks keep their python (or Perl, or Bash etc.) in /usr/local/bin\nor in $HOME, that's why this construct is needed at all.\n\nChanging environment variables is not the goal, insofar this usage\nexploits only a side-effect of env.  It is portable in practice because\nenv is in /usr/bin on most modern systems.\n\nSo you could replace this first line of a bash script:\n\n   #!/usr/bin/env python\n\nwith this:\n\n   #!python\n\nexcept that the latter doesn't work because you need to specify an\nabsolute path there. :]\n\nRene\n"},{"id":"2586","messageId":"42790B8A.9010406@tmr.com","threadId":"449","inReplyTo":"4277B15F.1020102@lsrfire.ath.cx","subject":"Re: Mercurial 0.4b vs git patchbomb benchmark","fromName":"Bill Davidsen","fromEmail":"davidsen@tmr.com","sentAt":"2005-05-04T17:51:06Z","receivedAt":"2005-05-04T17:51:06Z","isPatch":false,"sender":{"key":"davidsen@tmr.com","avatar":null},"body":"Rene Scharfe wrote:\n> Bill Davidsen schrieb:\n> \n>>On the theory that my first post got lost, why use /usr/bin/env at \n>>all, when bash already does that substitution? To support people who \n>>use other shells?\n>>\n>>ie.: FOO=xx perl -e '$a=$ENV{FOO}; print \"$a\\n\"'\n> \n> \n> /usr/bin/env is used in scripts in the shebang line (the very first line\n> of the script, starting with \"#!\", which denotes the interpreter to use\n> for that script) to make a PATH search for the real interpreter.\n> Some folks keep their python (or Perl, or Bash etc.) in /usr/local/bin\n> or in $HOME, that's why this construct is needed at all.\n> \n> Changing environment variables is not the goal, insofar this usage\n> exploits only a side-effect of env.  It is portable in practice because\n> env is in /usr/bin on most modern systems.\n> \n> So you could replace this first line of a bash script:\n> \n>    #!/usr/bin/env python\n> \n> with this:\n> \n>    #!python\n> \n> except that the latter doesn't work because you need to specify an\n> absolute path there. :]\n\nAssuming that you want the PATH search rather than a symlink in \n/usr/bin, of course. This opens the door to forgetting you just loaded \nthe CVS daily of python into your test directory and doing an unplanned \ntest of alpha software, but if people think the application should work \nwith non-standard tool chains, and realize it has possible unwanted \neffects, that's a design decision.\n\n-- \n    -bill davidsen (davidsen@tmr.com)\n\"The secret to procrastination is to put things off until the\n  last possible moment - but no longer\"  -me\n"}]}