Re: set -e in (subshells) does not work independently of outer context

[Eric Blake]

On 01/30/2012 02:27 PM, Linda Walsh wrote:
> 
> 
> Chet Ramey wrote:
> 
>> As Eric said, the other parts of the Posix description make it clear that
>> the `ignoring set -e' status is inherited by subshells.
> 
> ----
>     The original POSIX standard made this clear -- in that
> it was only a failure of a 'simple' command that resulted' in
> an err-exit'.

Have you not read the link I pointed to?  The whole point of
http://austingroupbugs.net/view.php?id=52 is a claim that the POSIX 2001
wording for 'set -e' was buggy, because it was inconsistent with
traditional practice, and therefore that particular bug report provides
the approved TC1 wording for how 'set -e' must behave, when using only
the shell features documented by POSIX.

> Since a subshell is not a 'simple command', it would not qualify
> just like ((n=0)) isn't a simple command, so shouldn't trigger an
> error exit...(but has in some recent versions)....

The corrected POSIX wording makes it clear that any command, simple or
otherwise, that does not meet the list of three exclusions, causes the
shell to exit.  It's just that the three exclusions are quite broad
(anything on the left side of a pipe && or ||, anything in the
conditional statement of a compound command, and anything except
subshells that has non-zero status due to a failed inner command in a
context where set -e did not abort the inner command).  Bash 4.2 took
great pains to comply to the POSIX wording in that particular bug
report, seeing as how the original wording in POSIX 2001 was deemed buggy.

> 
> Is that fixed in bash  now?

Yes, bash 4.2 strives to obey the POSIX wording as set forth in POSIX
bug 52.  The fact that earlier bash versions did not obey the later
POSIX wording, and were therefore incompatible with ksh behavior, is a
historical wart due to the wording bug in POSIX.

That said, ((n=0)) is not described by POSIX.  Here, bash might do
better to treat ((n=0)) the same way as ksh, even though in isolation,
it is a command exiting with non-zero status.

$ bash -c 'set -e; ((foo=0)); echo $?.$foo'
$ ksh -c 'set -e; ((foo=0)); echo $?.$foo'
1.0

Or, put another way, if POSIX were to standardize (()), then it would
probably have to amend bug 52 to describe whether (()) forms a fourth
exception to the list of commands where set -e does not cause an exit on
non-zero status.  But without a standard to follow, the fact that ksh
and bash differ in behavior is a fact of life, and you shouldn't be
using non-POSIX extensions if you want your script to be portable to
both shells.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature