Dear Bash maintainers,
After reviewing the original laboratory test and earlier reports, I need to
correct the Repeat-By and qualify the conclusions in my previous message.
The pasted conditional expression contains a formatting error: \vert{}\vert{}
should be the shell operator ||.
More importantly, fixing that typo does not validate the measurement. The
supplied harness:
*
does not synchronize with trap installation;
*
ignores failures when sending the signal;
*
treats survival after only 50 ms as signal loss;
*
combines parser errors and timeout outcomes in one counter.
Please disregard that harness as a validated measurement of lost signals.
The original laboratory subject recovered during this review was:
h() { printf 'HANDLER\n' >&2; exit 130; }
trap h INT TERM
f() {
local v
v=$(printf '%s' "$1")
printf -v r '%s' "$v"
}
while :; do f abc; done
Its surrounding test injected TERM and checked for termination over 40
intervals of 50 ms. The historical counts should not have been associated with
the different nested-substitution script in my email. Without the corresponding
per-trial evidence, exceeding a deadline should be reported as a timeout rather
than automatically classified as a lost signal.
The injection code provided also does not establish the SIGINT claim in the
subject line. TERM and INT need separate validation.
There are relevant earlier reports:
*
September 2023 report concerning CHLD traps and command
substitutions<https://lists.gnu.org/archive/html/bug-bash/2023-09/msg00058.html>.
*
February 2024 response referring to the earlier
correction<https://lists.gnu.org/archive/html/bug-bash/2024-02/msg00029.html>.
In Bash 5.3, parse_command guards run_pending_traps against
command-substitution parsing, unlike the 5.2.21 source. The development
changelog attributes this change to the September 2023 report.
This provides a concrete investigation path: compare the original subject on
5.2.21 and a current patched 5.3, recording successful signal delivery, handler
output, parser diagnostics, exit status and elapsed time separately. I have not
performed that comparison during this review, so I cannot yet establish whether
my observed case is identical to the known issue or resolved by that change.
Please treat the connection to parse_comsub as a hypothesis rather than a
demonstrated root cause, and the novelty and affected-version scope as
unestablished. Could you indicate whether this original subject is likely
covered by the known parser/trap correction?
Apologies for the imprecision in the initial report, and thank you for your
time.
Best regards,
Edgar Magdelaine
________________________________
De : Edgar MAGDELAINE <[email protected]>
Envoyé : mardi 13 octobre 2026 23:05
À : [email protected] <[email protected]>
Objet : [Bash 5.2.21] Trapped signal (SIGTERM/SIGINT) lost with false
"unexpected EOF" when received during command substitution parsing
Dear Bash Maintainers,
First and foremost, I wish to express my deep appreciation and utmost respect
for the titanic work you have accomplished over the decades in developing and
maintaining GNU Bash. While conducting high-frequency signal reliability tests
on
long-running diagnostic scripts, we isolated a reproducible signal loss case
during command substitution parsing that we hope will be useful to you.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Bash Version: 5.2
Patch Level: 21
Release Status: release
Description:
When a script with a registered signal trap (`trap '...' TERM INT`) repeatedly
evaluates command substitutions `$(...)` and receives the trapped signal while
Bash is internally parsing the command substitution (`parse_comsub`), Bash
intermittently emits a spurious syntax error:
trap: line N: unexpected EOF while looking for matching `)'
When this occurs, the trap handler is aborted/not executed, and the main script
continues running as if the signal had never been received.
Across 300 trials on Ubuntu 24.04 (Bash 5.2.21, kernel 6.18), this results in
25 to 28 lost termination signals per 300 runs (approx. 8-9% failure rate).
Running the exact same test under `dash` results in 0 lost signals out of 300.
Repeat-By:
Run the following standalone harness:
#!/usr/bin/env bash
losses=0; trials=200
for (( i = 1; i <= trials; i++ )); do
out=$(
"$BASH" -c '
trap "echo CAUGHT; exit 0" TERM
while :; do
x=$( : $( :$( : ) ) )
done
' 2>&1 &
pid=$!
sleep 0.03
kill -TERM "$pid" 2>/dev/null
sleep 0.05
if kill -0 "$pid" 2>/dev/null; then
kill -KILL "$pid" 2>/dev/null
echo "LOST"
fi
wait "$pid" 2>/dev/null
)
[[ $out == LOST \vert{}\vert{}$out == "unexpected EOF" ]] && (( losses++ ))
done
printf 'Bash %s: %d lost signal(s) out of %d trials ' "$BASH_VERSION" "$losses"
"$trials"
Thank you once again for your monumental contribution to the Unix and Linux
community, and for taking the time to examine this report.
With my highest regards and most respectful salutations,
Edgar Magdelaine
