{"thread":{"id":"4804","subject":"[Patch] Using 'perl' in *.sh","startedAt":"2006-07-08T15:32:04Z","lastAt":"2006-07-10T13:29:38Z","messageCount":16,"participants":["Michal Rokos","Junio C Hamano","Alex Riesen","Jan-Benedict Glaw","Yakov Lerner","Randal L. Schwartz","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"23416","messageId":"200607081732.04273.michal.rokos@nextsoft.cz","threadId":"4804","inReplyTo":null,"subject":"[Patch] Using 'perl' in *.sh","fromName":"Michal Rokos","fromEmail":"michal.rokos@nextsoft.cz","sentAt":"2006-07-08T15:32:04Z","receivedAt":"2006-07-08T15:32:04Z","isPatch":true,"sender":{"key":"michal.rokos@nextsoft.cz","avatar":null},"body":"Hi,\n\nsome GIT's shell script are using bare 'perl' for perl invocation. It's \ncausing me problems... I compile git with PERL_PATH set and I'd suggest to \nuse it everywhere.\n\nSo @@PERL@@ would be replaced with PERL_PATH_SQ instead.\n\nWhat do you think?\n\nMichal\n\nSigned-off-by: Michal Rokos <michal.rokos@nextsoft.cz>\n\ndiff --git a/Makefile b/Makefile\nindex 202f261..8f9881f 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -514,6 +514,7 @@ common-cmds.h: Documentation/git-*.txt\n $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh\n \trm -f $@ $@+\n \tsed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \\\n+\t    -e 's!@@PERL@@!$(PERL_PATH_SQ)!g' \\\n \t    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n \t    -e 's/@@NO_CURL@@/$(NO_CURL)/g' \\\n \t    -e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \\\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 03df143..06a8d26 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -13,7 +13,7 @@ git bisect log\t\t\tshow bisect log.'\n . git-sh-setup\n \n sq() {\n-\tperl -e '\n+\t@@PERL@@ -e '\n \t\tfor (@ARGV) {\n \t\t\ts/'\\''/'\\'\\\\\\\\\\'\\''/g;\n \t\t\tprint \" '\\''$_'\\''\";\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 6a14b25..0368803 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -324,7 +324,7 @@ test -d \"$GIT_DIR/refs/reference-tmp\" &&\n if test -f \"$GIT_DIR/CLONE_HEAD\"\n then\n \t# Read git-fetch-pack -k output and store the remote branches.\n-\tperl -e \"$copy_refs\" \"$GIT_DIR\" \"$use_separate_remote\" \"$origin\"\n+\t@@PERL@@ -e \"$copy_refs\" \"$GIT_DIR\" \"$use_separate_remote\" \"$origin\"\n fi\n \n cd \"$D\" || exit\ndiff --git a/git-commit.sh b/git-commit.sh\nindex 22c4ce8..08d786d 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -147,7 +147,7 @@ #'\n \t    git-ls-files -z --others $option \\\n \t\t--exclude-per-directory=.gitignore\n \tfi |\n-\tperl -e '$/ = \"\\0\";\n+\t@@PERL@@ -e '$/ = \"\\0\";\n \t    my $shown = 0;\n \t    while (<>) {\n \t\tchomp;\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex 48818f8..f80299d 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -278,7 +278,7 @@ fetch_main () {\n \t  head=\"ref: $remote_name\"\n \t  while (expr \"z$head\" : \"zref:\" && expr $depth \\< $max_depth) >/dev/null\n \t  do\n-\t    remote_name_quoted=$(perl -e '\n+\t    remote_name_quoted=$(@@PERL@@ -e '\n \t      my $u = $ARGV[0];\n               $u =~ s/^ref:\\s*//;\n \t      $u =~ s{([^-a-zA-Z0-9/.])}{sprintf\"%%%02x\",ord($1)}eg;\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 3945e06..1b9e986 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -311,7 +311,7 @@ echo \"$prev_head\" > \"$dotest/prev_head\"\n \n msgnum=0\n for cmt in `git-rev-list --no-merges \"$upstream\"..ORIG_HEAD \\\n-\t\t\t| perl -e 'print reverse <>'`\n+\t\t\t| @@PERL@@ -e 'print reverse <>'`\n do\n \tmsgnum=$(($msgnum + 1))\n \techo \"$cmt\" > \"$dotest/cmt.$msgnum\"\n\n-- \nMichal Rokos\n\nNextSoft s.r.o.\nVyskočilova 1/1410\n140 21 Praha 4\nphone:  +420 267 224 311\nfax:    +420 267 224 307\nmobile: +420 736 646 591\ne-mail: michal.rokos@nextsoft.cz\n"},{"id":"23421","messageId":"7v3bdcq7dy.fsf@assigned-by-dhcp.cox.net","threadId":"4804","inReplyTo":"200607081732.04273.michal.rokos@nextsoft.cz","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-08T18:27:37Z","receivedAt":"2006-07-08T18:27:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michal Rokos <michal.rokos@nextsoft.cz> writes:\n\n> Hi,\n>\n> some GIT's shell script are using bare 'perl' for perl invocation. It's \n> causing me problems... I compile git with PERL_PATH set and I'd suggest to \n> use it everywhere.\n>\n> So @@PERL@@ would be replaced with PERL_PATH_SQ instead.\n>\n> What do you think?\n\nAbsolutely.\n\nI think it was just sloppiness that we did not do so already.\nThanks.\n"},{"id":"23464","messageId":"20060709094630.GB5919@steel.home","threadId":"4804","inReplyTo":"7v3bdcq7dy.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-07-09T09:46:30Z","receivedAt":"2006-07-09T09:46:30Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Sat, Jul 08, 2006 20:27:37 +0200:\n> >\n> > some GIT's shell script are using bare 'perl' for perl invocation. It's \n> > causing me problems... I compile git with PERL_PATH set and I'd suggest to \n> > use it everywhere.\n> >\n> > So @@PERL@@ would be replaced with PERL_PATH_SQ instead.\n> >\n> > What do you think?\n> \n> Absolutely.\n\nNow imagine a non-posix system where an upgrade was made. Amongst\nother things perl was moved, i.e. from /opt/perl-5.8.8 to\n/usr/local/{bin,lib}. Suddenly git breaks.\n"},{"id":"23466","messageId":"20060709095114.GQ22573@lug-owl.de","threadId":"4804","inReplyTo":"20060709094630.GB5919@steel.home","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-07-09T09:51:15Z","receivedAt":"2006-07-09T09:51:15Z","isPatch":true,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Sun, 2006-07-09 11:46:30 +0200, Alex Riesen <fork0@t-online.de> wrote:\n> Junio C Hamano, Sat, Jul 08, 2006 20:27:37 +0200:\n> > >\n> > > some GIT's shell script are using bare 'perl' for perl invocation. It's \n> > > causing me problems... I compile git with PERL_PATH set and I'd suggest to \n> > > use it everywhere.\n> > >\n> > > So @@PERL@@ would be replaced with PERL_PATH_SQ instead.\n> > >\n> > > What do you think?\n> > \n> > Absolutely.\n> \n> Now imagine a non-posix system where an upgrade was made. Amongst\n> other things perl was moved, i.e. from /opt/perl-5.8.8 to\n> /usr/local/{bin,lib}. Suddenly git breaks.\n\nMy personal oppinion is to call perl scripts as `perl foo.pl' and thus\nlet the user decide (by means of setting $PATH) which perl incarnation\nshe wants to use.\n\nMfG, JBG\n\n-- \nJan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _\n\"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O\n für einen Freien Staat voll Freier Bürger\"  | im Internet! |   im Irak!   O O O\nret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));\n"},{"id":"23468","messageId":"f36b08ee0607090309l3cc05b19t44781bbe26013a0b@mail.gmail.com","threadId":"4804","inReplyTo":"20060709094630.GB5919@steel.home","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Yakov Lerner","fromEmail":"iler.ml@gmail.com","sentAt":"2006-07-09T10:09:30Z","receivedAt":"2006-07-09T10:09:30Z","isPatch":true,"sender":{"key":"iler.ml@gmail.com","avatar":null},"body":"On 7/9/06, Alex Riesen <fork0@t-online.de> wrote:\n> Junio C Hamano, Sat, Jul 08, 2006 20:27:37 +0200:\n> > >\n> > > some GIT's shell script are using bare 'perl' for perl invocation. It's\n> > > causing me problems... I compile git with PERL_PATH set and I'd suggest to\n> > > use it everywhere.\n> > >\n> > > So @@PERL@@ would be replaced with PERL_PATH_SQ instead.\n> > >\n> > > What do you think?\n> >\n> > Absolutely.\n>\n> Now imagine a non-posix system where an upgrade was made. Amongst\n> other things perl was moved, i.e. from /opt/perl-5.8.8 to\n> /usr/local/{bin,lib}. Suddenly git breaks.\n\nBuilding new perl for sources never removed,\nby itself, older perls on the system. Did it ever for you ?\nHow would installing new perl into new location\nbreak git ? It would only break if you *remove*\nold perl, not if you install new perl into new\nlocation, no ?\n\nYakov\n"},{"id":"23469","messageId":"7vd5cfnkz4.fsf@assigned-by-dhcp.cox.net","threadId":"4804","inReplyTo":"20060709095114.GQ22573@lug-owl.de","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-09T10:14:39Z","receivedAt":"2006-07-09T10:14:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:\n\n> My personal oppinion is to call perl scripts as `perl foo.pl' and thus\n> let the user decide (by means of setting $PATH) which perl incarnation\n> she wants to use.\n\nSounds sane, and I was wrong.\n\nWe should be able to do that for perl (we cannot in general do\nthat for GNU tools since some people seem to like renaming them\nfrom foo to gfoo).\n\nMichal, is there a reason you do not want to have the version of\nperl you teach git tools via #! lines with PERL_PATH on your $PATH?\n"},{"id":"23474","messageId":"20060709121706.GD5919@steel.home","threadId":"4804","inReplyTo":"f36b08ee0607090309l3cc05b19t44781bbe26013a0b@mail.gmail.com","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Alex Riesen","fromEmail":"fork0@t-online.de","sentAt":"2006-07-09T12:17:07Z","receivedAt":"2006-07-09T12:17:07Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Yakov Lerner, Sun, Jul 09, 2006 12:09:30 +0200:\n> >Now imagine a non-posix system where an upgrade was made. Amongst\n> >other things perl was moved, i.e. from /opt/perl-5.8.8 to\n> >/usr/local/{bin,lib}. Suddenly git breaks.\n> \n> Building new perl for sources never removed,\n> by itself, older perls on the system. Did it ever for you ?\n\nNo. But a strange package management program will remove the old perl.\n"},{"id":"23475","messageId":"200607091441.16161.michal.rokos@nextsoft.cz","threadId":"4804","inReplyTo":"7vd5cfnkz4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Michal Rokos","fromEmail":"michal.rokos@nextsoft.cz","sentAt":"2006-07-09T12:41:15Z","receivedAt":"2006-07-09T12:41:15Z","isPatch":true,"sender":{"key":"michal.rokos@nextsoft.cz","avatar":null},"body":"Hello,\n\nOn Sunday 09 July 2006 12:14, Junio C Hamano wrote:\n> Michal, is there a reason you do not want to have the version of\n> perl you teach git tools via #! lines with PERL_PATH on your $PATH?\n\nI have no problem with that. I can set $PATH.\nBut then I'd suggest to change magic #!\nfrom #!/usr/bin/perl\nto #!/usr/bin/env perl\nfor *.perl\n\nIt that what you meant?\n\nM.\n\nPS: Please note that\n#!/usr/bin/env perl -w\nwill not work on some platforms (at least on HP-UX)...\n-- \nMichal Rokos\n\nNextSoft s.r.o.\nVyskočilova 1/1410\n140 21 Praha 4\nphone:  +420 267 224 311\nfax:    +420 267 224 307\nmobile: +420 736 646 591\ne-mail: michal.rokos@nextsoft.cz\n"},{"id":"23477","messageId":"86ejwuuba2.fsf@blue.stonehenge.com","threadId":"4804","inReplyTo":"200607091441.16161.michal.rokos@nextsoft.cz","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-07-09T14:02:13Z","receivedAt":"2006-07-09T14:02:13Z","isPatch":true,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Michal\" == Michal Rokos <michal.rokos@nextsoft.cz> writes:\n\nMichal> I have no problem with that. I can set $PATH.\nMichal> But then I'd suggest to change magic #!\nMichal> from #!/usr/bin/perl\nMichal> to #!/usr/bin/env perl\nMichal> for *.perl\n\nMichal> It that what you meant?\n\nNo, don't do that.  Use the path to Perl that they chose during\nconfiguration because\n\n(a) it might not be the first one in PATH\n(b) even if it's the first one in *my* path, it might not be the\n    first one in *everyone's* path\n(c) env requires an *extra* fork/exec\n(d) some systems don't have env\n\nThe env hack is a nice hack, but it's just a hack.  Don't\nrely on it when the right thing is nearby.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"23486","messageId":"20060709162407.GV22573@lug-owl.de","threadId":"4804","inReplyTo":"86ejwuuba2.fsf@blue.stonehenge.com","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-07-09T16:24:07Z","receivedAt":"2006-07-09T16:24:07Z","isPatch":true,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Sun, 2006-07-09 07:02:13 -0700, Randal L. Schwartz <merlyn@stonehenge.com> wrote:\n> >>>>> \"Michal\" == Michal Rokos <michal.rokos@nextsoft.cz> writes:\n> \n> Michal> I have no problem with that. I can set $PATH.\n> Michal> But then I'd suggest to change magic #!\n> Michal> from #!/usr/bin/perl\n> Michal> to #!/usr/bin/env perl\n> Michal> for *.perl\n> \n> Michal> It that what you meant?\n> \n> No, don't do that.  Use the path to Perl that they chose during\n> configuration because\n> \n> (a) it might not be the first one in PATH\n\nIf you want to execute some binary that's not first in path, you'd\nbetter *always* call that explicit.\n\n> (b) even if it's the first one in *my* path, it might not be the\n>     first one in *everyone's* path\n\nCommunication problem. Machine's administrator should offer a working\ngit installation. If a user chooses to build his own git, he'd better\nmake sure that all the environment is properly set-up, too.\n\n> (c) env requires an *extra* fork/exec\n\nOnly an extra exec.\n\n> (d) some systems don't have env\n\nHuh? Show me a system that has no /usr/bin/env, but a working POSIX\nshell in /bin/sh .\n\n> The env hack is a nice hack, but it's just a hack.  Don't\n> rely on it when the right thing is nearby.\n\nWhat's the right thing? The right thing is to explicitely call the\ninterpreter, not using the shellbang at all.\n\nMfG, JBG\n\n-- \nJan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _\n\"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O\n für einen Freien Staat voll Freier Bürger\"  | im Internet! |   im Irak!   O O O\nret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));\n"},{"id":"23490","messageId":"7v4pxqfri7.fsf@assigned-by-dhcp.cox.net","threadId":"4804","inReplyTo":"200607091441.16161.michal.rokos@nextsoft.cz","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-09T20:33:04Z","receivedAt":"2006-07-09T20:33:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michal Rokos <michal.rokos@nextsoft.cz> writes:\n\n> Hello,\n>\n> On Sunday 09 July 2006 12:14, Junio C Hamano wrote:\n>> Michal, is there a reason you do not want to have the version of\n>> perl you teach git tools via #! lines with PERL_PATH on your $PATH?\n>\n> I have no problem with that. I can set $PATH.\n> But then I'd suggest to change magic #!\n> from #!/usr/bin/perl\n> to #!/usr/bin/env perl\n> for *.perl\n>\n> It that what you meant?\n\nNo, that is not what I meant.\n\nInvocation of perl _in_ scripts can be controlled by user's\nPATH, but #! cannot be.  As Merlyn says 'env' is a nice hack,\nbut we configure the scripts we install to have #!  pointing at\nthe right interpreter as a more cleaner (than using 'env', that\nis) workaround anyway, so #! pointing at PERL_PATH and scripts\nrelying on user's $PATH would be the right thing to do.\n"},{"id":"23492","messageId":"20060709212051.GW22573@lug-owl.de","threadId":"4804","inReplyTo":"7v4pxqfri7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2006-07-09T21:20:51Z","receivedAt":"2006-07-09T21:20:51Z","isPatch":true,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Sun, 2006-07-09 13:33:04 -0700, Junio C Hamano <junkio@cox.net> wrote:\n> Michal Rokos <michal.rokos@nextsoft.cz> writes:\n> > On Sunday 09 July 2006 12:14, Junio C Hamano wrote:\n> >> Michal, is there a reason you do not want to have the version of\n> >> perl you teach git tools via #! lines with PERL_PATH on your $PATH?\n> >\n> > I have no problem with that. I can set $PATH.\n> > But then I'd suggest to change magic #!\n> > from #!/usr/bin/perl\n> > to #!/usr/bin/env perl\n> > for *.perl\n> >\n> > It that what you meant?\n> \n> No, that is not what I meant.\n\nThough I think you actually should :-)\n\n> Invocation of perl _in_ scripts can be controlled by user's\n> PATH, but #! cannot be.  As Merlyn says 'env' is a nice hack,\n> but we configure the scripts we install to have #!  pointing at\n> the right interpreter as a more cleaner (than using 'env', that\n> is) workaround anyway, so #! pointing at PERL_PATH and scripts\n> relying on user's $PATH would be the right thing to do.\n\nIt's just a question of the target system, so: What is our target? If\nwe target a fairly recent Unix box, we'd put whatever a user asked for\ninto the shellbang, and hope that he properly sets $PATH.\n\nIf we try to aim at POSIX systems, then first of all, `env' isn't a\nhack. It's specified i the POSIX documents, even argument passing is\ngiven. (So if `#!/usr/bin/env perl -w' doesn't work on a HP-UX system,\nthat's simply broken wrt. POSIX.)\n\nAt the maximum, we'd allow the user to supply the location of `env' if\nit's not /usr/bin/env, but I guess you'll find a hard time finding a\nsystem where there's no /usr/bin/env...  The final killer would be to\nexplicitely mention the interpreter and install all scripts a-x to\nforce that :-)\n\nMfG, JBG\n\n-- \nJan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _\n\"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O\n für einen Freien Staat voll Freier Bürger\"  | im Internet! |   im Irak!   O O O\nret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));\n"},{"id":"23519","messageId":"200607100741.26377.michal.rokos@nextsoft.cz","threadId":"4804","inReplyTo":"7v4pxqfri7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Michal Rokos","fromEmail":"michal.rokos@nextsoft.cz","sentAt":"2006-07-10T05:41:26Z","receivedAt":"2006-07-10T05:41:26Z","isPatch":true,"sender":{"key":"michal.rokos@nextsoft.cz","avatar":null},"body":"Hi,\n\nOn Sunday 09 July 2006 22:33, Junio C Hamano wrote:\n> Invocation of perl _in_ scripts can be controlled by user's\n> PATH, but #! cannot be.  As Merlyn says 'env' is a nice hack,\n> but we configure the scripts we install to have #!  pointing at\n> the right interpreter as a more cleaner (than using 'env', that\n> is) workaround anyway, so #! pointing at PERL_PATH and scripts\n> relying on user's $PATH would be the right thing to do.\n\nI don't se the point. If you ask me, I'd say it should be either:\n- controlled fully via env: which means 'perl' in scripts and /usr/bin/env in \n*.perl; or\n- set during install: which means 'full perl path' in scripts as well as in \n*.perl\n\nAny mixture of above makes no sence to me. I'm afraid that any consensus will \nbe hard to reach, but I don't see any other way round. (Well maybe some git \nspecific exec wrapper to come over some broken 'env' commands)\n\nM.\n\n-- \nMichal Rokos\n\nNextSoft s.r.o.\nVyskočilova 1/1410\n140 21 Praha 4\nphone:  +420 267 224 311\nfax:    +420 267 224 307\nmobile: +420 736 646 591\ne-mail: michal.rokos@nextsoft.cz\n"},{"id":"23545","messageId":"86veq5sj22.fsf@blue.stonehenge.com","threadId":"4804","inReplyTo":"200607100741.26377.michal.rokos@nextsoft.cz","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-07-10T13:09:25Z","receivedAt":"2006-07-10T13:09:25Z","isPatch":true,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Michal\" == Michal Rokos <michal.rokos@nextsoft.cz> writes:\n\nMichal> I don't se the point. If you ask me, I'd say it should be either:\nMichal> - controlled fully via env: which means 'perl' in scripts and /usr/bin/env in \nMichal> *.perl; or\n\nwhich *pointlessly* doesn't work if *I* have installed a private Perl and a\nprivate git on a large shared systems, and *you* on the same system want to\nuse my git installation, but not necessarily have my Perl in your path.\n\nThere's *no* point to the env hack.  You're *installing* the file, which means\nyou can *rewrite* it as needed.  The env hack is a quick hack in case you have\na no-install file (something you're rsync'ing from one machine to another) for\nstrictly personal use.  Don't introduce that to something like the formal\ngit installation.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"23548","messageId":"Pine.LNX.4.63.0607101514410.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4804","inReplyTo":"86veq5sj22.fsf@blue.stonehenge.com","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-07-10T13:16:05Z","receivedAt":"2006-07-10T13:16:05Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 10 Jul 2006, Randal L. Schwartz wrote:\n\n> >>>>> \"Michal\" == Michal Rokos <michal.rokos@nextsoft.cz> writes:\n> \n> Michal> I don't se the point. If you ask me, I'd say it should be either:\n> Michal> - controlled fully via env: which means 'perl' in scripts and /usr/bin/env in \n> Michal> *.perl; or\n> \n> which *pointlessly* doesn't work if *I* have installed a private Perl and a\n> private git on a large shared systems, and *you* on the same system want to\n> use my git installation, but not necessarily have my Perl in your path.\n\n... so, git depends on perl. You know what that means...\n\nCiao,\nDscho\n"},{"id":"23550","messageId":"86fyh9si4d.fsf@blue.stonehenge.com","threadId":"4804","inReplyTo":"Pine.LNX.4.63.0607101514410.29667@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [Patch] Using 'perl' in *.sh","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-07-10T13:29:38Z","receivedAt":"2006-07-10T13:29:38Z","isPatch":true,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Johannes\" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\nJohannes> ... so, git depends on perl. You know what that means...\n\nFine.  perl has to be installed for git to work, and not necessarily in my\npath.  You know what *that* means. :)\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"}]}