Re: difftool uses hardcoded perl shebang
Jeff King writes: > On Tue, Dec 19, 2017 at 09:08:44AM -0800, Junio C Hamano wrote: > >> Jeff King 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.
Re: difftool uses hardcoded perl shebang
On Tue, Dec 19, 2017 at 09:08:44AM -0800, Junio C Hamano wrote: > Jeff King 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
Jeff King 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
On Tue, Dec 19, 2017 at 08:33:22AM -0800, Junio C Hamano wrote: > Jeff King 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
Jeff King 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
On Tue, Dec 19, 2017 at 01:28:09PM +, 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 /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
Please disregard that line, it just a mailing client attachment. It is completely irrelevant to the matter. -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: 19 December 2017 17:13 To: Jakub Zaverka Cc: git@vger.kernel.org Subject: Re: difftool uses hardcoded perl shebang Jakub Zaverka 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
Jakub Zaverka writes: > The below email is classified: Internal Internal to what?
