On 9/27/25 11:15 AM, Stan Marsh wrote:
Observe (note that I am testing with 5.3rc2, which is the latest version I have access to ATM):First, go to a terminal on $somehost and do: netcat -vv -lp $someport then do: ~/Build/bash-5.3-rc2 $ ./bash ; echo "Bash has exited!" $ echo $BASH_VERSION 5.3.0(1)-rc2 $ exec 3<>/dev/tcp/$somehost/$someport
This is a socket; sockets are essentially identical to pipes for the purposes of this report.
At this point, I hit ^C on the netcat, causing it to exit, then do:
$ echo hello and again >&3
$ echo hello and again >&3
Status: 141
Bash has exited!
$
I find both of the following less than optimal:
1) That you have to do it twice to get it to exit (why twice?). This is
not a
fluke or a one-off; it seems to be consistent.
Bash doesn't control this. It's whenever the kernel sends the SIGPIPE.
2) That the bash shell crashes and doesn't handle it gracefully.
SIGPIPE is a fatal signal. The shell catches it, cleans up, and resends SIGPIPE to itself. That's as graceful as needed.
Update: I realized while composing this that you probably need to trap SIGPIPE
in the
shell. So, I added:
$ trap 'echo OK;let trapped++' PIPE
$ echo hello >&3
bash: echo: write error: Broken pipe
bash: DEBUG warning: run_pending_traps: recursive invocation while running trap
for
signal 66
If NSIG is 65, then yes, signal 66 is ERR. If `trapped' is 0 when this
is run, the trap action will return 1 and trigger the ERR trap again.
(The wisdom of recursively running traps is debateable, but people have
requested it.)
And yes, if you trap SIGPIPE, the write will still fail with -1/EPIPE,
and bash will tell you.
--
``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
Description: OpenPGP digital signature
