On Thu, 11 Jun 2026 at 08:37, Alex Chernyakhovsky <[email protected]> wrote:
> > 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 a reason why parentheses denoting a subshell should be treated any differently from any other compound command? (I can maybe see a point to having «.» and «eval» treated differently, but that's a different argument.) Is there any chance we could reopen the discussion if this is actually the > desired interpretation? Changing the current behaviour of Bash would likely crash some scripts that are currently working correctly. To my mind that trumps compatibility with other shells and should even limit POSIX conformance in the absence of an explicit «set -o posix» or «#!/bin/sh». > Having multiple allegedly POSIX-compliant shells in use that have very > different behavior here makes it difficult to write portable code To be clear, changes between versions of Bash are not your only obstacle. Surveying several shells, dash behaves as you've requested, but ksh and zsh align with the behaviour of recent versions of Bash. (See PPS below for details) Bash changed between version 3.2.48 and version 4.0.0, the same release that added associative arrays. (It is a thankful mercy that Apple has removed Bash 3 from new Darwin releases; its locked-in antique behaviour has been a thorn in the side of Bash script authors; even most embedded systems use at least Bash 4.2.) > 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. It's not hard to make portable scripts: simply write explicit tests rather than relying on "set -e" as the only protection. Run regression test suites both with and without it, and if the results differ, do not deploy. -Martin PS: or just skip the shell entirely and write in a more mainstream language, preferably that's defined by an open reference implementation such as Python or Perl. PPS: > $ cat ~/tmp/S > echo B > false > echo C > -------- > ii dash 0.5.12-12 amd64 POSIX-compliant shell > $ dash -c set -e ; ( echo A ; . ~/tmp/S ; echo D ) || : ; echo E > A > B > E > -------- > GNU bash, version 3.2.48(82)-release (x86_64-unknown-linux-gnu) > $ bash-3.2.48p82-release -c set -e ; ( echo A ; . ~/tmp/S ; echo D ) || : > ; echo E > A > B > E > -------- > GNU bash, version 4.0.0(1)-maint (x86_64-unknown-linux-gnu) > $ bash-4.0.0p1-maint -c set -e ; ( echo A ; . ~/tmp/S ; echo D ) || : ; > echo E > A > B > C > D > E > -------- > GNU bash, version 5.3.0(14)-maint (x86_64-pc-linux-gnu) > $ bash-latest -c set -e ; ( echo A ; . ~/tmp/S ; echo D ) || : ; echo E > A > B > C > D > E > -------- > zsh 5.9 (x86_64-debian-linux-gnu) > $ zsh -c set -e ; ( echo A ; . ~/tmp/S ; echo D ) || : ; echo E > A > B > C > D > E > -------- > ksh version sh (AT&T Research) 93u+m/1.0.10 2024-08-01 > $ ksh -c set -e ; ( echo A ; . ~/tmp/S ; echo D ) || : ; echo E > A > B > C > D > E
