Re: Regression with subshells and set -e

Chet Ramey <[email protected]> Wed, 10 Jun 2026 11:35:11 -0400
Newsgroups gmane.comp.shells.bash.bugs
Organization ITS, Case Western Reserve University
Message-ID <[email protected]>
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.

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/
OpenPGP_signature.asc (application/pgp-signature, 203 B)
-----BEGIN PGP SIGNATURE-----

wmMEABEIACMWIQR8ATX7CIqvbGbGULm7WGnwZOp0qwUCaimELwUDAAAAAAAKCRC7WGnwZOp0q6T7
AJ0f48glrX1lGnJjV1fEy0GdKeBq5QCfWKAeZXXeZ5MztGDrm4Hg9h57d+o=
=qjli
-----END PGP SIGNATURE-----