patchgitweb-lib.sh: Set up PATH to use perl from /usr/bin

When there are different version of perl installed on the machine, the $PATH may point out a different version of perl than /usr/bin. One example is to have /opt/local/bin/perl before /usr/bin/perl.

Sanitize the PATH by adding /usr/bin at the beginning

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
On my Mac OS machine t9501-gitweb-standalone-http-status.sh failed because
perl was found under /opt/local/bin instead of of /usr/bin.

/opt/local/bin is coming from Macports. The problem with different perl installations on the same machine may hit more people than just me.

There are different solutions, please help to find the best one:

a) Delete perl from /opt/local/bin b) Put /opt/local/bin at the end of the PATH c) Change gitweb-lib.sh to set up the PATH to /usr/bin, because that is what the file gitweb_config.perl generated by gitweb-lib.sh expects.

 t/gitweb-lib.sh |    3 +++
 1 file changed, 3 insertions(+)

On 05/01/2012 01:23 PM, Torsten Bögershausen wrote:

Hm, I see that most scripts have #!/usr/bin/perl, and only two have #!env perl [1]. So in general we usally rely on using perl in /usr/bin.

But your patch affects other stuff than perl, and unconditionally changing PATH set by the user is not nice, as it affect programs called recursively. Wouldn't simply replacing all calls to bare perl in t/gitweb-lib.sh with invocations of /usr/bin/perl be better?

[1] % git grep 'env perl\b' git-relink.perl:#!/usr/bin/env perl git-svn.perl:#!/usr/bin/env perl

- Zbyszek

On Tue, May 01, 2012 at 06:23:37PM +0200, Zbigniew Jędrzejewski-Szmek wrote:

The Makefile substitutes $PERL_PATH on the #!-line of each perl script during its "build" step (which is really just copying the file to its final name and running "chmod +x").

So even though the source files say /usr/bin/perl, we are not relying on that. If you look at the Makefile rule carefully, you will see that even "#!/usr/bin/env perl" gets replaced, too. Those scripts should probably be updated, since the mention of env is simply confusing.

Yes, although they should use $PERL_PATH rather than hardcoding /usr/bin.

-Peff

Zbigniew Jędrzejewski-Szmek  <zbyszek@in.waw.pl> writes:

The #!/usr/bin/env variants should be eradicated. Our Makefile rewrites "#!.*perl" with "#!$PERL_PATH" in scripted Porcelains before installing, so /usr/bin/perl is the right thing to write there.

On 05/01/2012 06:47 PM, Junio C Hamano wrote:

This would be trivial, as it is only two files.

But I don't see why we would use a different perl in git-am.sh: perl -ne 'BEGIN { $subject = 0 } git-am.sh: perl -M'POSIX qw(strftime)' -ne 'BEGIN { $subject = 0 } git-request-pull.sh:ref=$(git ls-remote "$url" | perl -e "$find_matching_ref" "$head" "$headrev") git-submodule.sh: perl -e ' test-sha1.sh: perl -pe 'y/\000/g/' test-sha1.sh: perl -pe 'y/\000/g/' and lot of files in t/. Shouldn't those be replaced too?

Jeff King wrote:

Thank you for the explanation. I never noticed this, since I don't set PERL_PATH myself.

Zbyszek

On Tue, May 01, 2012 at 07:03:39PM +0200, Zbigniew Jędrzejewski-Szmek wrote:

No. There are two ways in which we use perl:

  1. To run our complex scripts like gitweb, git-svn, etc. These require
     a reasonably modern perl version, and the user must specify it with
     PERL_PATH if it is not in /usr/bin.

  2. To run little snippets that _could_ be written in sed or awk, but
     which cause portability problems on crappy versions of those tools.
     These should run under any version of perl5.

It's OK to use 'perl' from the path for (2), because we are not asking very much of perl in that case.

I think the patch we want is just:

Thanks for all answers,

Yes, it does.

Should we go for that solution ?

/Torsten

Torsten Bögershausen <tboegi@web.de> writes:

Sounds good.

The current code runs "perl gitweb.cgi" to test gitweb. This will use whatever version of perl happens to be first in the PATH. We are better off using the specific perl that the user specified via PERL_PATH, which matches what gets put on the #!-line of the built gitweb.cgi.

Signed-off-by: Jeff King <peff@peff.net>
---
On Tue, May 01, 2012 at 07:50:44PM +0200, Torsten Bögershausen wrote:

OK, here it is with a commit message.

 t/gitweb-lib.sh |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

While the majority of scripts use '#!/usr/bin/perl', some use '#!/usr/bin/env perl'. In the end there is no difference, because the Makefile rewrites "#!.*perl" with "#!$PERL_PATH" in scripted Porcelains before installing. Nevertheless, the second form can be misleading, because it suggests that perl found first in $PATH will be used.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
 git-relink.perl |    2 +-
 git-svn.perl    |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Zbigniew> Suggested-by: Junio C Hamano <gitster@pobox.com> Zbigniew> Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>

And I strongly support this change. Too many things use that env trick, and it really isn't the proper solution to this.

Torsten Bögershausen <tboegi@web.de> writes:

This is wrong.

What makes you think /usr/bin always has saner version of tools than those in the directories that the user explicitly listed earlier on her $PATH?

If anything it should be honoring $PERL_PATH that is set in the Makefile.