Re: .ONESHELL enhancement?

[Paul Smith]

On Wed, 2009-09-23 at 14:26 -0400, David Boyce wrote:
> On Wed, Sep 23, 2009 at 1:57 PM, Paul Smith <address@hidden> wrote:
> > It seems to me that we might be able to get close to this, with the
> > following changes:
> >
> >     1. Add -e to the shell invocation by default if .POSIX is set.
> >     2. Use the simple "pass the entire thing to the shell, unmodified"
> >        version of the .ONESHELL implementation.
> >
> > After this, adding both .POSIX and .ONESHELL (could be easily done by
> > setting a MAKEFILES environment variable to a file containing those
> > targets, before invoking make) will get you very nearly what you are
> > looking for, I think.
> 
> General agreement, I think, except for a few nits:
> 
> - How does this address the command-line issues?

It definitely does not.  I was purposefully trying to compartmentalize
the effort.  I think this can be done first, using a hardcoded value the
same way "-c" is handled.

Then later (if we like) we can add the last item needed for the generic
interpreter facility, which would be .SHELLFLAGS or whatever.

> - Can we assume that assigning to SHELL absolves us of the need to
> follow POSIX? Because I think there's no way to guarantee (or even
> define) "set -e" behavior with an arbitrary interpreter.

The way I read the POSIX spec, we do not need to (and I would definitely
not want to) actually add a real "set -e" to the command line before
passing it to the shell.

What I was envisioning for this first, partial step would be to modify
the code in job.c:construct_command_argv_internal() so that if POSIX was
set it would invoke the shell with "-ec", and if not it would invoke it
with "-c" (see the minus_c[] string setting--needs a little cleanup
here).

And, as above, leave the more complicated stuff for another project
(unless you wanted to take that on as well, of course).

As far as setting SHELL, the standard says that "effects of defining
SHELL in the makefile or on the command line are
implementation-defined".  GNU make already has a method for determining
if a value for SHELL is a POSIX-y shell or not, used to decide whether
to even attempt to use the fast path.  I think that method would
continue to be used unchanged here.

> - The hack to remove address@hidden from interior recipe lines would have to 
> be
> contingent on SHELL not being reassigned. It could wreak havoc on a
> Perl script, for instance.

That's a good idea.  It might be a good compromise.  Let's think about
that.

> - I thought I remembered that .POSIX disables certain useful
> extensions, but I don't see any reference to that in the  manual for
> 3.81. Am I remembering wrong?

.POSIX doesn't do much at all today; it only manages something to do
with MAKEFLAGS IIRC.

> The number of permutations implied by .POSIX, .ONESHELL, SHELL, and
> .SHELLFLAGS is worrisome. Perhaps certain combinations can be
> disallowed or ignored?

I guess I was thinking that .ONESHELL and .POSIX wouldn't be at all
related _directly_.  It's just that in your particular case you would
want to use them both, because you want both behaviors.

.POSIX and SHELL aren't interconnected either, I don't think.

As for the future .SHELLFLAGS, if .POSIX is set it would change the
default value of .SHELLFLAGS from "-c" to "-ec".  Obviously
setting .SHELLFLAGS in the makefile would take precedence over that.