[RFC/PATCH 0/3] perl

[Jeff King <peff@peff.net>]

On Mon, Oct 28, 2013 at 02:04:20PM -0700, Jonathan Nieder wrote:

> Jeff King wrote:
> 
> > Speaking of which, is there any reason to use the ugly "$PERL_PATH"
> > everywhere, and not simply do:
> >
> >   perl () {
> >     "$PERL_PATH" "$@"
> >   }
> >
> > in test-lib.sh?
> 
> Sounds like a nice potential improvement to me. :)

One answer to "is there any reason..." is "it will loop infinitely if
you set PERL_PATH=perl". :) However, we can work around that with
"command".

It also may cause problems due to the way one-shot variables are treated
when calling a function versus a command, but we do not seem to set any
variables for invocations perl (and I do not envision it happening
often).

And finally, the other reason I can think of is that we can't apply it
consistently. It only helps where a shell function would activate, which
makes the end result potentially more confusing (especially to somebody
who does not really grok shells and subprocesses). Still, it does not
introduce any _new_ cases that need it, but only helps with a subset of
the cases. So in that sense it is a strict improvement, as we can let
most uses go, but catch only the trickier cases in review.

So I'm on the fence on whether it is a good idea or not, but I wrote up
the patches to play with it. I also noticed that we do not consistently
use $PERL_PATH in some of the built scripts, so I included that fix,
too.

Note that I do not have a system with a broken perl. I simulated a very
broken perl, which is how I found all of the spots to fix. But whether
they are actual bugs that would trigger due to a Windows perl that
handles CRLF differently, I have no clue.

  [1/3]: use @@PERL@@ in built scripts
  [2/3]: t: provide a perl() function which uses $PERL_PATH
  [3/3]: t: use perl instead of "$PERL_PATH" where applicable

-Peff