On Wed, Dec 10, 2003 at 01:32:12PM +0000, Ben Harris wrote:
> On Tue, 9 Dec 2003, James Chacon wrote:
> 
> > On Wed, Dec 10, 2003 at 12:40:45AM +0000, Ben Harris wrote:
> > > In article <m2n.s.1ATpUq-000hYr@chiark.greenend.org.uk> you write:
> > > >        (cd ${.CURDIR} && make bar)
> > > >
> > > >According to SUSE3:
> > > >
> > > >-e When this option is on, if a simple command fails for any of the reasons
> > > >   listed in Consequences of Shell Errors or returns an exit status value >0,
> > > >   and is not part of the compound list following a while, until, or if
> > > >   keyword, and is not a part of an AND or OR list, and is not a pipeline
> > > >   preceded by the ! reserved word, then the shell shall immediately exit.
> > >
> > > Note "simple command".  A group like "(false)" is not a simple command.  The
> > > command "false" is a simple command, but it's executed in a subshell
> > > environment.
> >
> > Compound commands are groups of simple commands. Nothing in the above
> > exclusions says the return code of these shouldn't be interpreted as far as
> > -e usage goes.
> 
> Indeed.  It's obvious that -e _should_ be interpreted for them.  The
> question is what "the shell shall immediately exit" means in the context
> of a command executed in a subshell.  Does it mean that the subshell
> exits, or that the parent shell exits?  In particular, should it mean
> something different from what happens when a subshell executes the "exit"
> command (all the shells I've tested agree that "exit" in a subshell
> _doesn't_ exit the parent).

The subshell should exit by normal rules and based on the fact that -e
transfers to it. (and return according to the rules for subshells
which is the exit code from the last command).

Past that I think it's obvious then that the parent would exit as it's got
the e flag set and it just had a command exit non-zero and it's not part
of the exclusion list of ones to ignore for checking on error. 

> 
> > > >2. Fix sh to deal with group'd commands and -e. Then provide nbsh as a host
> > > >   tool and tell make to use it.
> 
> > > >(I'm leaning towards #2 but I need opinions/knowledge on whether sh is
> > > >doing the right thing or not.)
> > >
> > > I think both behaviours are arguably correct, and since it's not terribly
> > > hard (if slightly ugly) to write scripts that cope with both, we should just
> > > do that.
> >
> > The concern is which one to use as a system.
> 
> That's fine.  You were suggesting shipping a replacement shell for the
> host system because writing POSIX shell scripts was beyond us earlier.
> As long as you're only proposing to change our /bin/sh, I'm happy.

I was saying fix our /bin/sh (to what I beleive is perfectly correctly
POSIX/SUSE behavior), possibly fix the Makefiles (though long term I beleive
adding || exit $? everywhere will get missed and this problem creep back in), 
and then provide /bin/sh as nbsh during builds so a known sh implementation
is available during builds.

James