[RFC/PATCH 0/3] perl

From: Jeff King <peff@peff.net>
Date: Oct 29, 2013, 01:18 UTC
Message-ID: <20131029011859.GA22140@sigill.intra.peff.net>
In-Reply-To: <20131028210420.GC4242@google.com>

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

Show 12 quoted lines

> 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