The exact language used in the Single UNIX specification to describe the meaning of
set -e is:
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 [a conditional or negated command], then the shell shall immediately exit.
There is an ambiguity as to what happens when such a command occurs in a subshell. From a practical point of view, all the subshell can do is exit and return a nonzero status to the parent shell. Whether the parent shell will in turn exit depends on whether this nonzero status translates into a simple command failing in the parent shell.
One such problematic case is the one you encountered: a nonzero return status from a command substitution. Since this status is ignored, it does not cause the parent shell to exit. As you've already discovered, a way to take the exit status into account is to use the command substitution in a simple assignment: then the exit status of the assignment is the exit status of the last command substitution in the assignment(s).
Note that this will perform as intended only if there is a single command substitution, as only the last substitution's status is taken into account. For example, the following command is successful (both according to the standard and in every implementation I've seen):
Another case to watch for is explicit subshells:
(somecommand). According to the interpretation above, the subshell may return a nonzero status, but since this is not a simple command in the parent shell, the parent shell should continue. In fact, all the shells I know of do make the parent return at this point. While this is useful in many cases such as
(cd /some/dir && somecommand) where the parentheses are used to keep an operation such as a current directory change local, it violates the specification if
set -e is turned off in the subshell, or if the subshell returns a nonzero status in a way that would not terminate it, such as using
! on a true command. For example, all of ash, bash, pdksh, ksh93 and zsh exit without displaying
foo on the following examples:
set -e; (set +e; false); echo "This should be displayed"
set -e; (! true); echo "This should be displayed"
Yet no simple command has failed while
set -e was in effect!
A third problematic case is elements in a nontrivial pipeline. In practice, all shells ignore failures of the elements of the pipeline other than the last one, and exhibit one of two behaviors regarding the last pipeline element:
- ATT ksh and zsh, which execute the last element of the pipeline in the parent shell, do business as usual: if a simple command fails in the last element of the pipeline, the shell executing that command, which happens to be the parent shell, exits.
- Other shells approximate the behavior by exiting if the last element of the pipeline returns a nonzero status.
Like before, turning off
set -e or using a negation in the last element of the pipeline causes it to return a nonzero status in a way that should not terminate the shell; shells other than ATT ksh and zsh will then exit.
pipefail option causes a pipeline to exit immediately under
set -e if any of its elements returns a nonzero status.
Note that as a further complication, bash turns off
set -e in subshells unless it's in POSIX mode (
set -o posix or have
POSIXLY_CORRECT in the environment when bash starts).
All of this shows that the POSIX specification unfortunately does a poor job at specifying the
-e option. Fortunately, existing shells are mostly consistent in their behavior.