Re: .ONESHELL enhancement?

[David Boyce]

On Wed, Sep 23, 2009 at 9:48 AM, Paul Smith <address@hidden> wrote:
> What you mean here is that to make .ONESHELL behavior be identical to
> current GNU make behavior, except that you get a potential performance
> boost and some simplicity in scripting, you would need && semantics.

Yes. And in my mind it's entirely clear that this is precisely what
the POSIX RATIONALE is talking about. Of course it's not normative;
there's no magic to interpreting what they were talking about. But for
the record, I think the && behavior is clearly implied.

> It would still WORK without them, it's just that error handling would be
> different.

Yes.

> However, I'm not necessarily convinced by this argument.  First, note
> that the latest POSIX standard mandates that make invoke shells with
> "set -e" enabled by default (a change, and a very serious one, from
> previous standards).  If you follow the standard here then adding "&&"
> is NOT required, since the script will error out immediately anyway due
> to -e.  Thus I don't think the standard intends that we should add "&&"
> at all.
>
> Unfortunately, GNU make does not (any longer) follow the standard here,
> so we're kind of stuck.

I do remember this fuss and it is a painful problem. Doesn't seem
POSIX-like to make such a significant change at this late date, and
they may not have realized what they were doing, but it's done and
yes, it's a problem. And also an opportunity, as you note below, for
the .ONESHELL behavior.

> I'm actually quite uneasy about attempts to interpret and modify the
> recipe string, even with something as ostensibly simple as concatenating
> logical lines with "&&".  IME, it's always very dangerous and difficult
> to make these kinds of changes without incurring nasty side-effects.

Agree, demons can lurk there. But remember, it's not a case of
changing default behavior. GNU make has worked fine for many years
without .ONESHELL; if someone tries it and runs into trouble, they can
take it back out. Not to be cavalier about any bug, but the stakes are
lower here. It's only the most sophisticated users who would even note
the existence of the new feature, understand its purpose, and try it.

> I think some of the examples Matt gives are quite telling: if a stated
> goal of .ONESHELL is to reduce the need for many continued lines then
> adding "&&" can cause problems: really instead of the fairly
> straightforward "the entire recipe is passed, as-is, to the shell", we
> have to discuss that each logical line in the recipe must be a
> self-enclosed shell statement.

I have to say that this line of argument makes no sense to me. First,
ISTM that the bit about reducing the need for many continued lines is
just a slightly sloppy way of saying it reduces the need to type "
&&\" at the end of each line. In other words I don't think any seismic
semantic change is being considered here; it's a throwaway line saying
"we could save some typing if we had this". Second, and more
important, isn't it already the case that "each logical line in the
recipe must be a self-enclosed shell recipe"? I assume that line
continuations are taken care of early in recipe parsing, so that what
shows up in file->cmds->commands shows no backslash-newline combos.
Since each such logical line is passed to the shell, it's either a
valid command or (properly) an error. What am I missing?

> Take Matt's example here:
>
>> foo: bar
>>         if test -s $<
>>         then
>>                 echo 'nonempty' >$@
>>         else
>>                 echo 'empty' >$@
>>         fi
>
> This cannot work; ALL of these must use backslashes:
>
>        foo: bar
>                if test -s $<; then \
>                        echo 'nonempty' >$@; \
>                else \
>                        echo 'empty' >$@; \
>                fi
>
> I really don't see how you simplify your recipe writing in this
> situation: any complex recipe must continue to use backslashes to be
> sure that "&&" is not introduced where it's not wanted/valid.

The (my) goal is not to simplify recipe writing; rather, the goal is a
100% compatible design which will use the same recipes with the same
semantics, just fewer shells.

> That's not even mentioning what happens if SHELL is set to something
> that's not a POSIX shell; if we have .ONESHELL it becomes (IMO) more
> likely someone will want to use a separate script interpreter like Perl
> or whatever (yes, I remember the -c flag problem but this can be worked
> around).  Do we only add "&&" if we know we have a POSIX shell (similar
> to the fastpath computation)?  This gets more and more complex.

Yes, this is a concern which bears further thought.

>From here down I will not quote your points individually because I
agree with all of them. WRT to how to handle the general POSIX
compatibility/set -e problem, that's kind of a separate discussion,
but your .SHELLFLAGS idea seems like the best option.

There would be a certain symmetry to only supporting .ONESHELL in
POSIX mode, since it's a POSIX idea, and presumably it becomes almost
trivial to implement if we can assume -e mode.

I have more to write on this subject but I think it's better done in a
separate subthread, so expect another msg soon.

DSB