threads / patch / 4804

patchUsing 'perl' in *.sh

Subject: [Patch] Using 'perl' in *.sh

## tl;dr

16 messages between Jul 8, 2006 and Jul 10, 2006. Diffs are folded; open one to read it.

replies: 15people: 7as markdown or json

Michal Rokos· Jul 8, 2006, 15:32 UTC · lore
Hi,

some GIT's shell script are using bare 'perl' for perl invocation. It's causing me problems... I compile git with PERL_PATH set and I'd suggest to use it everywhere.

So @@PERL@@ would be replaced with PERL_PATH_SQ instead.
What do you think?
Michal
Signed-off-by: Michal Rokos <michal.rokos@nextsoft.cz>
Show changes to 6 files +6 −5

Makefile, git-bisect.sh, git-clone.sh, git-commit.sh, git-fetch.sh, git-rebase.sh

diff --git a/Makefile b/Makefile
index 202f261..8f9881f 100644
--- a/Makefile
+++ b/Makefile
@@ -514,6 +514,7 @@ common-cmds.h: Documentation/git-*.txt
 $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
 	rm -f $@ $@+
 	sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+	    -e 's!@@PERL@@!$(PERL_PATH_SQ)!g' \
 	    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
 	    -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
 	    -e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \
diff --git a/git-bisect.sh b/git-bisect.sh
index 03df143..06a8d26 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -13,7 +13,7 @@ git bisect log			show bisect log.'
 . git-sh-setup
 
 sq() {
-	perl -e '
+	@@PERL@@ -e '
 		for (@ARGV) {
 			s/'\''/'\'\\\\\'\''/g;
 			print " '\''$_'\''";
diff --git a/git-clone.sh b/git-clone.sh
index 6a14b25..0368803 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -324,7 +324,7 @@ test -d "$GIT_DIR/refs/reference-tmp" &&
 if test -f "$GIT_DIR/CLONE_HEAD"
 then
 	# Read git-fetch-pack -k output and store the remote branches.
-	perl -e "$copy_refs" "$GIT_DIR" "$use_separate_remote" "$origin"
+	@@PERL@@ -e "$copy_refs" "$GIT_DIR" "$use_separate_remote" "$origin"
 fi
 
 cd "$D" || exit
diff --git a/git-commit.sh b/git-commit.sh
index 22c4ce8..08d786d 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -147,7 +147,7 @@ #'
 	    git-ls-files -z --others $option \
 		--exclude-per-directory=.gitignore
 	fi |
-	perl -e '$/ = "\0";
+	@@PERL@@ -e '$/ = "\0";
 	    my $shown = 0;
 	    while (<>) {
 		chomp;
diff --git a/git-fetch.sh b/git-fetch.sh
index 48818f8..f80299d 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -278,7 +278,7 @@ fetch_main () {
 	  head="ref: $remote_name"
 	  while (expr "z$head" : "zref:" && expr $depth \< $max_depth) >/dev/null
 	  do
-	    remote_name_quoted=$(perl -e '
+	    remote_name_quoted=$(@@PERL@@ -e '
 	      my $u = $ARGV[0];
               $u =~ s/^ref:\s*//;
 	      $u =~ s{([^-a-zA-Z0-9/.])}{sprintf"%%%02x",ord($1)}eg;
diff --git a/git-rebase.sh b/git-rebase.sh
index 3945e06..1b9e986 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -311,7 +311,7 @@ echo "$prev_head" > "$dotest/prev_head"
 
 msgnum=0
 for cmt in `git-rev-list --no-merges "$upstream"..ORIG_HEAD \
-			| perl -e 'print reverse <>'`
+			| @@PERL@@ -e 'print reverse <>'`
 do
 	msgnum=$(($msgnum + 1))
 	echo "$cmt" > "$dotest/cmt.$msgnum"

-- 
Michal Rokos

NextSoft s.r.o.
Vyskočilova 1/1410
140 21 Praha 4
phone:  +420 267 224 311
fax:    +420 267 224 307
mobile: +420 736 646 591
e-mail: michal.rokos@nextsoft.cz
Junio C Hamano· Jul 8, 2006, 18:27 UTC · re: Michal Rokos · lore

Re: [Patch] Using 'perl' in *.sh

Michal Rokos <michal.rokos@nextsoft.cz> writes:
Show 9 quoted lines
> Hi,
>
> some GIT's shell script are using bare 'perl' for perl invocation. It's 
> causing me problems... I compile git with PERL_PATH set and I'd suggest to 
> use it everywhere.
>
> So @@PERL@@ would be replaced with PERL_PATH_SQ instead.
>
> What do you think?
Absolutely.

I think it was just sloppiness that we did not do so already. Thanks.

Alex Riesen· Jul 9, 2006, 09:46 UTC · re: Junio C Hamano · lore

Re: [Patch] Using 'perl' in *.sh

Junio C Hamano, Sat, Jul 08, 2006 20:27:37 +0200:
Show 10 quoted lines
> >
> > some GIT's shell script are using bare 'perl' for perl invocation. It's 
> > causing me problems... I compile git with PERL_PATH set and I'd suggest to 
> > use it everywhere.
> >
> > So @@PERL@@ would be replaced with PERL_PATH_SQ instead.
> >
> > What do you think?
> 
> Absolutely.

Now imagine a non-posix system where an upgrade was made. Amongst other things perl was moved, i.e. from /opt/perl-5.8.8 to /usr/local/{bin,lib}. Suddenly git breaks.

Jan-Benedict Glaw· Jul 9, 2006, 09:51 UTC · re: Alex Riesen · lore

Re: [Patch] Using 'perl' in *.sh

On Sun, 2006-07-09 11:46:30 +0200, Alex Riesen <fork0@t-online.de> wrote:
Show 15 quoted lines
> Junio C Hamano, Sat, Jul 08, 2006 20:27:37 +0200:
> > >
> > > some GIT's shell script are using bare 'perl' for perl invocation. It's 
> > > causing me problems... I compile git with PERL_PATH set and I'd suggest to 
> > > use it everywhere.
> > >
> > > So @@PERL@@ would be replaced with PERL_PATH_SQ instead.
> > >
> > > What do you think?
> > 
> > Absolutely.
> 
> Now imagine a non-posix system where an upgrade was made. Amongst
> other things perl was moved, i.e. from /opt/perl-5.8.8 to
> /usr/local/{bin,lib}. Suddenly git breaks.

My personal oppinion is to call perl scripts as `perl foo.pl' and thus let the user decide (by means of setting $PATH) which perl incarnation she wants to use.

MfG, JBG
-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Junio C Hamano· Jul 9, 2006, 10:14 UTC · re: Jan-Benedict Glaw · lore

Re: [Patch] Using 'perl' in *.sh

Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
> My personal oppinion is to call perl scripts as `perl foo.pl' and thus
> let the user decide (by means of setting $PATH) which perl incarnation
> she wants to use.
Sounds sane, and I was wrong.

We should be able to do that for perl (we cannot in general do that for GNU tools since some people seem to like renaming them from foo to gfoo).

Michal, is there a reason you do not want to have the version of perl you teach git tools via #! lines with PERL_PATH on your $PATH?

Michal Rokos· Jul 9, 2006, 12:41 UTC · re: Junio C Hamano · lore

Re: [Patch] Using 'perl' in *.sh

Hello,
On Sunday 09 July 2006 12:14, Junio C Hamano wrote:
> Michal, is there a reason you do not want to have the version of
> perl you teach git tools via #! lines with PERL_PATH on your $PATH?

I have no problem with that. I can set $PATH. But then I'd suggest to change magic #! from #!/usr/bin/perl to #!/usr/bin/env perl for *.perl

It that what you meant?
M.
PS: Please note that
#!/usr/bin/env perl -w
will not work on some platforms (at least on HP-UX)...
-- 
Michal Rokos

NextSoft s.r.o.
Vyskočilova 1/1410
140 21 Praha 4
phone:  +420 267 224 311
fax:    +420 267 224 307
mobile: +420 736 646 591
e-mail: michal.rokos@nextsoft.cz
Randal L. Schwartz· Jul 9, 2006, 14:02 UTC · re: Michal Rokos · lore

Re: [Patch] Using 'perl' in *.sh

>>>>> "Michal" == Michal Rokos <michal.rokos@nextsoft.cz> writes:

Michal> I have no problem with that. I can set $PATH. Michal> But then I'd suggest to change magic #! Michal> from #!/usr/bin/perl Michal> to #!/usr/bin/env perl Michal> for *.perl

Michal> It that what you meant?

No, don't do that. Use the path to Perl that they chose during configuration because

(a) it might not be the first one in PATH
(b) even if it's the first one in *my* path, it might not be the
    first one in *everyone's* path
(c) env requires an *extra* fork/exec
(d) some systems don't have env

The env hack is a nice hack, but it's just a hack. Don't rely on it when the right thing is nearby.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Jan-Benedict Glaw· Jul 9, 2006, 16:24 UTC · re: Randal L. Schwartz · lore

Re: [Patch] Using 'perl' in *.sh

On Sun, 2006-07-09 07:02:13 -0700, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
Show 14 quoted lines
> >>>>> "Michal" == Michal Rokos <michal.rokos@nextsoft.cz> writes:
> 
> Michal> I have no problem with that. I can set $PATH.
> Michal> But then I'd suggest to change magic #!
> Michal> from #!/usr/bin/perl
> Michal> to #!/usr/bin/env perl
> Michal> for *.perl
> 
> Michal> It that what you meant?
> 
> No, don't do that.  Use the path to Perl that they chose during
> configuration because
> 
> (a) it might not be the first one in PATH

If you want to execute some binary that's not first in path, you'd better *always* call that explicit.

> (b) even if it's the first one in *my* path, it might not be the
>     first one in *everyone's* path

Communication problem. Machine's administrator should offer a working git installation. If a user chooses to build his own git, he'd better make sure that all the environment is properly set-up, too.

> (c) env requires an *extra* fork/exec
Only an extra exec.
> (d) some systems don't have env

Huh? Show me a system that has no /usr/bin/env, but a working POSIX shell in /bin/sh .

> The env hack is a nice hack, but it's just a hack.  Don't
> rely on it when the right thing is nearby.

What's the right thing? The right thing is to explicitely call the interpreter, not using the shellbang at all.

MfG, JBG
-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Junio C Hamano· Jul 9, 2006, 20:33 UTC · re: Michal Rokos · lore

Re: [Patch] Using 'perl' in *.sh

Michal Rokos <michal.rokos@nextsoft.cz> writes:
Show 13 quoted lines
> Hello,
>
> On Sunday 09 July 2006 12:14, Junio C Hamano wrote:
>> Michal, is there a reason you do not want to have the version of
>> perl you teach git tools via #! lines with PERL_PATH on your $PATH?
>
> I have no problem with that. I can set $PATH.
> But then I'd suggest to change magic #!
> from #!/usr/bin/perl
> to #!/usr/bin/env perl
> for *.perl
>
> It that what you meant?
No, that is not what I meant.

Invocation of perl _in_ scripts can be controlled by user's PATH, but #! cannot be. As Merlyn says 'env' is a nice hack, but we configure the scripts we install to have #! pointing at the right interpreter as a more cleaner (than using 'env', that is) workaround anyway, so #! pointing at PERL_PATH and scripts relying on user's $PATH would be the right thing to do.

Jan-Benedict Glaw· Jul 9, 2006, 21:20 UTC · re: Junio C Hamano · lore

Re: [Patch] Using 'perl' in *.sh

On Sun, 2006-07-09 13:33:04 -0700, Junio C Hamano <junkio@cox.net> wrote:
Show 14 quoted lines
> Michal Rokos <michal.rokos@nextsoft.cz> writes:
> > On Sunday 09 July 2006 12:14, Junio C Hamano wrote:
> >> Michal, is there a reason you do not want to have the version of
> >> perl you teach git tools via #! lines with PERL_PATH on your $PATH?
> >
> > I have no problem with that. I can set $PATH.
> > But then I'd suggest to change magic #!
> > from #!/usr/bin/perl
> > to #!/usr/bin/env perl
> > for *.perl
> >
> > It that what you meant?
> 
> No, that is not what I meant.
Though I think you actually should :-)
Show 6 quoted lines
> Invocation of perl _in_ scripts can be controlled by user's
> PATH, but #! cannot be.  As Merlyn says 'env' is a nice hack,
> but we configure the scripts we install to have #!  pointing at
> the right interpreter as a more cleaner (than using 'env', that
> is) workaround anyway, so #! pointing at PERL_PATH and scripts
> relying on user's $PATH would be the right thing to do.

It's just a question of the target system, so: What is our target? If we target a fairly recent Unix box, we'd put whatever a user asked for into the shellbang, and hope that he properly sets $PATH.

If we try to aim at POSIX systems, then first of all, `env' isn't a hack. It's specified i the POSIX documents, even argument passing is given. (So if `#!/usr/bin/env perl -w' doesn't work on a HP-UX system, that's simply broken wrt. POSIX.)

At the maximum, we'd allow the user to supply the location of `env' if it's not /usr/bin/env, but I guess you'll find a hard time finding a system where there's no /usr/bin/env... The final killer would be to explicitely mention the interpreter and install all scripts a-x to force that :-)

MfG, JBG
-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Michal Rokos· Jul 10, 2006, 05:41 UTC · re: Junio C Hamano · lore

Re: [Patch] Using 'perl' in *.sh

Hi,
On Sunday 09 July 2006 22:33, Junio C Hamano wrote:
Show 6 quoted lines
> Invocation of perl _in_ scripts can be controlled by user's
> PATH, but #! cannot be.  As Merlyn says 'env' is a nice hack,
> but we configure the scripts we install to have #!  pointing at
> the right interpreter as a more cleaner (than using 'env', that
> is) workaround anyway, so #! pointing at PERL_PATH and scripts
> relying on user's $PATH would be the right thing to do.
I don't se the point. If you ask me, I'd say it should be either:
- controlled fully via env: which means 'perl' in scripts and /usr/bin/env in 
*.perl; or
- set during install: which means 'full perl path' in scripts as well as in 
*.perl

Any mixture of above makes no sence to me. I'm afraid that any consensus will be hard to reach, but I don't see any other way round. (Well maybe some git specific exec wrapper to come over some broken 'env' commands)

M.
-- 
Michal Rokos

NextSoft s.r.o.
Vyskočilova 1/1410
140 21 Praha 4
phone:  +420 267 224 311
fax:    +420 267 224 307
mobile: +420 736 646 591
e-mail: michal.rokos@nextsoft.cz
Randal L. Schwartz· Jul 10, 2006, 13:09 UTC · re: Michal Rokos · lore

Re: [Patch] Using 'perl' in *.sh

>>>>> "Michal" == Michal Rokos <michal.rokos@nextsoft.cz> writes:

Michal> I don't se the point. If you ask me, I'd say it should be either: Michal> - controlled fully via env: which means 'perl' in scripts and /usr/bin/env in Michal> *.perl; or

which *pointlessly* doesn't work if *I* have installed a private Perl and a private git on a large shared systems, and *you* on the same system want to use my git installation, but not necessarily have my Perl in your path.

There's *no* point to the env hack. You're *installing* the file, which means you can *rewrite* it as needed. The env hack is a quick hack in case you have a no-install file (something you're rsync'ing from one machine to another) for strictly personal use. Don't introduce that to something like the formal git installation.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Johannes Schindelin· Jul 10, 2006, 13:16 UTC · re: Randal L. Schwartz · lore

Re: [Patch] Using 'perl' in *.sh

Hi,
On Mon, 10 Jul 2006, Randal L. Schwartz wrote:
Show 9 quoted lines
> >>>>> "Michal" == Michal Rokos <michal.rokos@nextsoft.cz> writes:
> 
> Michal> I don't se the point. If you ask me, I'd say it should be either:
> Michal> - controlled fully via env: which means 'perl' in scripts and /usr/bin/env in 
> Michal> *.perl; or
> 
> which *pointlessly* doesn't work if *I* have installed a private Perl and a
> private git on a large shared systems, and *you* on the same system want to
> use my git installation, but not necessarily have my Perl in your path.
... so, git depends on perl. You know what that means...

Ciao, Dscho

Randal L. Schwartz· Jul 10, 2006, 13:29 UTC · re: Johannes Schindelin · lore

Re: [Patch] Using 'perl' in *.sh

>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Johannes> ... so, git depends on perl. You know what that means...

Fine. perl has to be installed for git to work, and not necessarily in my path. You know what *that* means. :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Yakov Lerner· Jul 9, 2006, 10:09 UTC · re: Alex Riesen · lore

Re: [Patch] Using 'perl' in *.sh

On 7/9/06, Alex Riesen <fork0@t-online.de> wrote:
Show 15 quoted lines
> Junio C Hamano, Sat, Jul 08, 2006 20:27:37 +0200:
> > >
> > > some GIT's shell script are using bare 'perl' for perl invocation. It's
> > > causing me problems... I compile git with PERL_PATH set and I'd suggest to
> > > use it everywhere.
> > >
> > > So @@PERL@@ would be replaced with PERL_PATH_SQ instead.
> > >
> > > What do you think?
> >
> > Absolutely.
>
> Now imagine a non-posix system where an upgrade was made. Amongst
> other things perl was moved, i.e. from /opt/perl-5.8.8 to
> /usr/local/{bin,lib}. Suddenly git breaks.

Building new perl for sources never removed, by itself, older perls on the system. Did it ever for you ? How would installing new perl into new location break git ? It would only break if you *remove* old perl, not if you install new perl into new location, no ?

Yakov
Alex Riesen· Jul 9, 2006, 12:17 UTC · re: Yakov Lerner · lore

Re: [Patch] Using 'perl' in *.sh

Yakov Lerner, Sun, Jul 09, 2006 12:09:30 +0200:
Show 6 quoted lines
> >Now imagine a non-posix system where an upgrade was made. Amongst
> >other things perl was moved, i.e. from /opt/perl-5.8.8 to
> >/usr/local/{bin,lib}. Suddenly git breaks.
> 
> Building new perl for sources never removed,
> by itself, older perls on the system. Did it ever for you ?
No. But a strange package management program will remove the old perl.

← back to recent threads