Re: Consequences of shell errors

[Eric Blake]

On 06/17/2015 04:33 PM, Nick Stoughton wrote:
> I was surprised when the following script did NOT exit at the indicated
> line:
> 
> set -e
> export X=$(false)
> # should not reach here

Why not?


> The export utility is a special built-in, and according to POSIX XCU 2.8.1
> "Consequences of Shell Errors", special built-ins should exit (with a
> diagnostic message) on both variable assignment error and expansion error.

But neither occurred.  Expansion trivially succeeded (expansion errors
are caused by variable expansion under set -u, not by command
substitution with non-zero status), and assignment succeeded (you
assigned the empty string to $X).

And because you did not execute command substitution in isolation, but
instead executed 'export', the $? status of the overall line is 0 (that
of export's successful assignment of nothing to X), not 1 (the
intermediate status of the command substitution).

> But every shell I tested behaves the same way (sh, bash, dash, ksh, mksh,
> yash and zsh), so I feel I must be missing something. Can someone explain
> why the first 2 examples do not exit on the error in the expansion?

Because failed $() can only exit the shell when done in a statement with
no command name.  Your workaround of splitting into:

X=$(false)
export X

is the only way to abort a shell under 'set -e' due to a failed command
substitution.

And this thread goes to show why we strongly recommend against using
'set -e' - it exists for historical practice, and does NOT generally do
what you think it should.

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

signature.asc
Description: OpenPGP digital signature