[Patch] Using 'perl' in *.sh

[Patch] Using 'perl' in *.sh

[Michal Rokos]

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>

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

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

[Junio C Hamano]

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

> 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.

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

[Alex Riesen]

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.

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

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

On Sun, 2006-07-09 11:46:30 +0200, Alex Riesen <fork0@t-online.de> wrote:
> 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));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Junio C Hamano]

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?

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

[Michal Rokos]

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

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

[Randal L. Schwartz]

>>>>> "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!

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

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

On Sun, 2006-07-09 07:02:13 -0700, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>> "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));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Junio C Hamano]

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

> 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.

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

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

On Sun, 2006-07-09 13:33:04 -0700, Junio C Hamano <junkio@cox.net> wrote:
> 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 :-)

> 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));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Michal Rokos]

Hi,

On Sunday 09 July 2006 22:33, Junio C Hamano wrote:
> 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

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

[Randal L. Schwartz]

>>>>> "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!

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

[Johannes Schindelin]

Hi,

On Mon, 10 Jul 2006, Randal L. Schwartz wrote:

> >>>>> "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

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

[Randal L. Schwartz]

>>>>> "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!

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

[Yakov Lerner]

On 7/9/06, Alex Riesen <fork0@t-online.de> wrote:
> 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

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

[Alex Riesen]

Yakov Lerner, Sun, Jul 09, 2006 12:09:30 +0200:
> >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.