Re: set -e loses exit status

[Dennis Lambe Jr.]

Quoting Chet Ramey <chet.ramey@case.edu>:

> I will change back to the pre-bash-4.1
> behavior for the next version.

That's fantastic. Thank you!

> There really isn't any requirement other than the
> exit status be non-zero

Since I bothered to dig through the standard, I'll document what I  
found here in case it's useful. This is all with the caveat that POSIX  
is quite vague on this question, so all anybody can do is try to read  
between the lines.

I would make the case that POSIX requires sh to return the exit status  
of the failing command, even when set -e is in effect.

Standard for set (including set -e):
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_25_03
"When this option is on, when any command fails (for any of the  
reasons listed in Consequences of Shell Errors or by returning an exit  
status greater than zero), the shell immediately shall exit  
[exceptions follow]"

Standard for exit status of sh:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html#tag_20_117_14
"The following exit values shall be returned:
[...]
1-125
    A non-interactive shell detected an error other than command_file  
not found, including but not limited to syntax, redirection, or  
variable assignment errors.
[...]
Otherwise, the shell shall return the exit status of the last command  
it invoked or attempted to invoke"

Since set -e mentions "shell errors" (enumerated above) and "non-zero  
exit status" as the two reasons a command might fail, I'd say that  
carries the implication that a non-zero exit status, while a "failure"  
in set -e's eyes, is not a "shell error". Since sh's exit status has  
to be the exit status of the last command executed unless an error was  
detected, a shell operating with set -e in effect still has to pass  
through the exit status of the command that caused it to exit.

Of course, one could say "trying to differentiate between a 'failure'  
and an 'error' is splitting hairs". One would be right. At the end of  
the day, the best argument is probably that the pre-bash-4.1 behavior  
is more useful. But there is further support in the fact that the  
standard very nearly almost sortof says it's the right thing to do.