difftool uses hardcoded perl shebang

The below email is classified: Internal

When running git difftool:

Perl lib version (5.10.0) doesn't match executable version (v5.16.3) Compilation failed in require at <path>/git-difftool line 2.

First line in my git-difftool is: #!/usr/bin/perl

I am using a specific perl that I cannot change. Similarly, I cannot change the git-difftool file. I would like the difftool to use the perl form my PATH. 

Maybe it would be better to use #!/usr/bin/env perl? ----------------------------------------- Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet.

The information contained in this message is confidential or protected by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited.

Legally required information for business correspondence/ Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz: http://deutsche-boerse.com/letterhead

Jakub Zaverka <jakub.zaverka@deutsche-boerse.com> writes:

Internal to what?

Please disregard that line, it just a mailing client attachment. It is completely irrelevant to the matter. 

-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com] 
Sent: 19 December 2017 17:13
To: Jakub Zaverka <jakub.zaverka@deutsche-boerse.com>
Cc: git@vger.kernel.org
Subject: Re: difftool uses hardcoded perl shebang

Jakub Zaverka <jakub.zaverka@deutsche-boerse.com> writes:

Internal to what? ----------------------------------------- Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet.

The information contained in this message is confidential or protected by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited.

Legally required information for business correspondence/ Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz: http://deutsche-boerse.com/letterhead

On Tue, Dec 19, 2017 at 01:28:09PM +0000, Jakub Zaverka wrote:

This is a build-time knob. When you build git, try:

  make PERL_PATH='/usr/bin/env perl'

(If you don't build your own git, then you might raise the issue with whomever packages your binary).

As an aside, git-difftool is now a C builtin these days, so the problem might also go away if you upgrade. ;)

-Peff

Jeff King <peff@peff.net> writes:

I somehow thought ANYTHING_PATH was meant to point at the exact path (as opposed to ANYTHING_COMMAND which is a command line), so it is within our rights to do

    test -x "$GIT_EXEC_PATH" || die "Your Git installation is broken"

but your suggestion above makes such a sanity check impossible.

I'd understand if it were

	make PERL_PATH=$(type --path perl)

of course, though.

Yup, true, true.

On Tue, Dec 19, 2017 at 08:33:22AM -0800, Junio C Hamano wrote:

Hmm, you're right. Though it looks like it is only the test scripts which actually use this feature. It would be nice if we supported this. Unfortunately it's hard to make both of these work:

  make PERL_PATH='/usr/bin/env perl'

  make PERL_PATH='/path with spaces/perl'

We must protect the spaces in the latter case and treat it as a single unit, but would not want to in the former.

In the meantime, pointing to the actual build-time perl is a workaround (but obviously not if it's being done by a third-party packager who has no idea where your perl is).

-Peff

Jeff King <peff@peff.net> writes:

Is such a binary packaging scheme actually in use that deliberately leaves it up to the end user where/if a perl is installed and if it is an appropriately recent version? It sounds rather irresponsible to me.

On Tue, Dec 19, 2017 at 09:08:44AM -0800, Junio C Hamano wrote:

No, I mean that the user can do:

  make PERL_PATH=/path/to/perl/in/my/PATH

but if they are not building Git themselves, that is not an option for them. And a binary packager cannot help them there, because they do not know that path.

-Peff

Jeff King <peff@peff.net> writes:

I think we are saying the same thing. A third-party binary packager cannot guess where your custom Perl is nor if it is recent enough. I just was wondering if such an irresponsible packaging scheme is in use that lets you install Git without somehow making sure that the box also has a version of Perl that can be used with the version of Git. Then the presence of /path/to/perl/in/my/PATH does not matter, as it does not have to be used with Git.