Re: [PATCH] global: resolve Perl executable via PATH

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Apr 6, 2023, 02:27 UTC
Message-ID: <CAMP44s2VuvP_mhLSXXyC1__GGYhfQM4Td-bghOE3AmqfQW0Czw@mail.gmail.com>
In-Reply-To: <xmqqv8iaw4n5.fsf@gitster.g>

On Wed, Apr 5, 2023 at 2:29 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 21 quoted lines

>
> Patrick Steinhardt <ps@pks.im> writes:
>
> >> I don't know what the right choice is for upstream Git, it
> >> can easily be argued in either direction. :)
> >
> > I agree, there is no clearly-superior choice -- both have their merits.
> > I'll probably send a v2 that only munges internal scripts that are used
> > as part of our build and testing infrastructure. That's the area I care
> > most about in this context anyway.
>
> My preference is
>
>  (1) not to touch scripts that are processed by Makefile to use
>      $PERL_PATH,
>
>  (2) fix callers of "./foo.pl" to invoke "$PERL_PATH ./foo.pl" where
>      the perl () { command "$PERL_PATH" "$@" } wrapper is not
>      avialable, and
>
>  (3) fix them to use "perl foo.pl" where the wrapper is visible.

That is orthogonal to the patch.

All those steps can be done *eventually* while the proposed patch is applied *today*.

> That way, we can wean ourselves away from the assumption that perl
> interpreter should exist at /usr/bin/perl without introducing a new
> assumption that everybody's env should exist at /usr/bin/env.

The patch doesn't introduce such an assumption.

Changing the shebang only affects scripts that are 1) not processed by the Makefile, and 2) not called as "${PERL_PATH-perl} foo.pl".

If your system does not have /usr/bin/env and everything you cared about worked yesterday, it would still work with the patch applied today.

Having a `#!/usr/bin/env perl` shebang is simply a good practice to write in all scripts.

But that is just the *default*, nobody is being forced to actually use that shebang because 1) the Makefile is still going to override that and replace it with $PERL_PATH in generated scripts, and 2) the scripts that do "$PERL_PATH ./foo.pl" are essentially overriding it to, and so does 3).

I believe this is a red herring (which might be desirable to fix some day).

Cheers.

-- 
Felipe Contreras