Jeff King wrote:

Hmm. I don't think that technique gives complete coverage. There are
other scripts (e.g., filter-branch) that call a bare "perl" (not
PERL_PATH), which presumably pass the tests even though they'd break in
a real-world system without perl. In fact, many scripts used to do this
before fcb06a8d54 (use @@PERL@@ in built scripts, 2013-10-28). I don't
think the effects on NO_PERL were really considered there; it was more
about finding the right perl.

Oh!  Thanks for looking deeper.

I think NO_PERL has historically mostly meant "do not build or install
perl scripts", and not "everything ought to run fine without perl".
We've generally assumed you can run vanilla perl snippets from the
command line the same way you'd run awk or sed (and the tests use this
extensively, which is why you have to set PERL_PATH again to run them).

Right.  PERL_PATH and NO_PERL are more orthogonal than I had thought.
So this is

  Not-Reviewed-by: Jonathan Nieder [off-list ref]

--- the patch shouldn't be applied as is.

That said, most of those casual uses of perl in actual built scripts
have gone away because the shell scripts have gone away. It looks like
filter-branch, request-pull, and instaweb are the last holdouts. So
maybe we should be treating NO_PERL as disabling those scripts, too.

But then, should we be doing more to make it clear that those scripts
are broken in a NO_PERL build? Who knows what happens if you run
filter-branch without any perl available?

Agreed: if we want to follow this approach, we should install stubs in
place of those scripts when NO_PERL=YesPlease.  Will say more about
this in a separate reply.

Thanks for catching it,
Jonathan