On Wed, Apr 5, 2023 at 2:29 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Patrick Steinhardt <ps@xxxxxx> 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
