Subject: Re: make -j and failure modes
To: James Chacon <>
From: Ben Harris <>
List: tech-userlevel
Date: 12/10/2003 13:32:12
On Tue, 9 Dec 2003, James Chacon wrote:

> On Wed, Dec 10, 2003 at 12:40:45AM +0000, Ben Harris wrote:
> > In article <> 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).

> > >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.

Ben Harris                                                   <>
Portmaster, NetBSD/acorn26           <URL:>