On 6/10/26 4:37 PM, Alex Chernyakhovsky wrote:

I appreciate the response. However, I find the current behavior
confusing and undesirable.

You're free to feel that way.

It is clear the subshell itself is part of
an AND-OR list, but I find the argument that the commands within the
subshell context are themselves part of the AND-OR list hard to buy
into.

Because a subshell environment is, in POSIX terms, created as "a duplicate
of the shell environment." The shell that is forked to run the commands in
the subshell command is a part of the AND-OR list, and ignores the -e
setting in the same way its parent would.

What makes the subshell different from a compound command such as { list; }
or a shell function? dash, for instance, carries the -e setting into both
of those compound commands. Is it simply the assumption that the shell
forks a child process, which it's not required to do?


Is there any chance we could reopen the discussion if this is actually
the desired interpretation?

If you would like to open an issue with the austin group, you can do so at
austingroupbugs.net (which is, unfortunately, down at the moment).


Having multiple allegedly POSIX-compliant
shells in use that have very different behavior here makes it
difficult to write portable code in shell if there are gotchas in what
is such a fundamental feature -- even if it just results in a
clarification of the POSIX text.

The behavior of `set -e' has always varied widely and is a rat's nest of
complexity.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [email protected]    http://tiswww.cwru.edu/~chet/

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to