On Wed, Jun 10, 2026 at 11:35 AM Chet Ramey <[email protected]> wrote: > > On 6/10/26 8:12 AM, Alex Chernyakhovsky wrote: > > Dear maintainer, > > > > I believe I have found a regression in bash when using subshells with > > set -e. I discovered this while looking through the logs of > > mirrors.mit.edu's sync jobs, and noticed that despite `set -e`, the > > script did not terminate when rsync returned non-zero. In case it is > > relevant, the sync scripts are available at > > https://github.com/sipb/mirrors-sync; fetch-hudson is the entry point, > > and ubuntu-archive is the one that I noticed triggered the behavior. > > > > Here's the minimized test case: > > > > ``` > > $ cat harness.sh <(echo '---') helper > > #!/bin/bash > > > > set -e > > > > echo "Sourcing helper" > > (. helper) && : > > echo "Helper exited with $?" > > In this script, set -e is ignored in the subshell because the subshell is > part of an AND-OR list. Even turning it on in the subshell has no effect. > The current version of the man page puts it this way: > > "If a compound command or shell function executes in a > context where -e is being ignored, none of the commands > executed within the compound command or function body > will be affected by the -e setting, even if -e is set > and a command returns a failure status. If a compound > command or shell function sets -e while executing in a > context where -e is ignored, that setting will not have > any effect until the compound command or the command > containing the function call completes." > > > > > I also double-checked the behavior against dash (0.5.12-12 from Debian > > Trixie), and dash acts like bash 4.2 and older: > > > > ``` > > $ dash harness.sh > > Sourcing helper > > In helper > > Helper exited with 1 > > ``` > > Behavior varies; dash has chosen an interpretation that I don't believe is > conformant. yash and ksh93, for instance, behave like bash. > > > > > I believe that bash's current behavior goes against the POSIX > > specification if my reading of > > https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html > > is correct. > > We had a long austin-group discussion about this back in 2009, and I > believe the current bash behavior reflects that discussion. >
I appreciate the response. However, I find the current behavior confusing and undesirable. 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. I specifically cannot understand why the behavior in the outer-context should affect the inner-context, as far as the compound is concerned the goal is to prevent early termination of the compound. Is there any chance we could reopen the discussion if this is actually the desired interpretation? 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. Sincerely, -Alex > Chet > > -- > ``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/
