difftool uses hardcoded perl shebang

difftool uses hardcoded perl shebang

[Jakub Zaverka]

The below email is classified: Internal

When running git difftool:

>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

Re: difftool uses hardcoded perl shebang

[Junio C Hamano]

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

> The below email is classified: Internal

Internal to what?

RE: difftool uses hardcoded perl shebang

[Jakub Zaverka]

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:

> The below email is classified: Internal

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

Re: difftool uses hardcoded perl shebang

[Jeff King]

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

> When running git difftool:
> 
> >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?

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

Re: difftool uses hardcoded perl shebang

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

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

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.

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

Yup, true, true.

Re: difftool uses hardcoded perl shebang

[Jeff King]

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

> Jeff King <peff@peff.net> writes:
> 
> > 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).
> 
> 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.

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

Re: difftool uses hardcoded perl shebang

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

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

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.

Re: difftool uses hardcoded perl shebang

[Jeff King]

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

> Jeff King <peff@peff.net> writes:
> 
> > 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).
> 
> 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.

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

Re: difftool uses hardcoded perl shebang

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Tue, Dec 19, 2017 at 09:08:44AM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > 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).
>> 
>> 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.
>
> 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.

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.