Subject: Re: make -j and failure modes
To: Robert Elz <kre@munnari.OZ.AU>
From: Ben Harris <bjh21@NetBSD.org>
List: tech-userlevel
Date: 12/10/2003 15:52:42
On Wed, 10 Dec 2003, Robert Elz wrote:

>     Date:        Wed, 10 Dec 2003 14:48:28 +0000 (GMT)
>     From:        Ben Harris <bjh21@NetBSD.org>
>     Message-ID:  <Pine.SOL.4.58.0312101410440.12032@draco.cus.cam.ac.uk>
>
>   | On Wed, 10 Dec 2003, James Chacon wrote:
>   |
>   | > 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.
>   |
>   | So you think that that the parent should treat the entire group of
>   | commands in the subshell as a single command, and exit if it fails, yes?
>
> I think that's what he is saying, but I believe it is clearly wrong.
>
> It is absurd to require the shell to look inside the commands run by the
> sub-shell and see if they're the kind that should cause "set -e" mode to
> cause the shell to exit - but not doing so would mean the parent shell exiting
> if the sub-shell exits with an error code, even though that error code didn't
> actually cause the sub-shell to exit 1 because of the -e.

Indeed.  I'm less than certain that this is actually a bad thing, though.
It seems that without looking inside subshells (which we agree is absurd),
you either make "(false)" behave differently from "false" (POSIX
behaviour, exemplified by Bash) or make "(false && true)" behave
differently from "false && true" (historical behaviour, exemplified by
ksh).  Either is unpleasant.

>   | but I'm having difficulty reconciling it with the POSIX
>   | definition of "-e", and in particular its statement that "-e" only applies
>   | to simple commands, which the group is not.
>
> Clearly not, and quite correctly, and I'm not surprised at your difficulty.

Thanks.  I think I now understand why POSIX is specified as it is, and as
such, I think it'd be reasonable for us to follow it.

-- 
Ben Harris                                                   <bjh21@NetBSD.org>
Portmaster, NetBSD/acorn26           <URL:http://www.NetBSD.org/Ports/acorn26/>