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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
