On Sat, 28 Sep 2024, Michael Kjörling wrote:
On 28 Sep 2024 16:28 +0100, from debianu...@woodall.me.uk (Tim Woodall):
Hmmm, I've managed to fix it. The problem seems to be related to using
echo in the exit trap itself while both stderr and stdout are redirected
- e.g. via |& tee log
If I change the echo in the trap function to /bin/echo then it works! (I
don't see the output anywhere but that isn't really a problem in this
case - I know why it's aborted!)
I still can't create a small testcase but maybe this gives someone a
clue what issue I'm hitting?
In this particular case it's almost certain that the tee program will
have gone away before the bash script calls the exit handler.
That last sentence seems _very_ relevant here.
If the other end of the pipe is gone, then the shell builtin `echo`
probably fails with SIGPIPE/EPIPE. So will /bin/echo too, of course,
but that will fail just that process, not the script or the /bin/bash
that is executing the script as is probably the case in your
situation. I suspect that if you dig into this, you will find that
everything works as expected up to that `echo` statement.
Check $? after /bin/echo in the handler (probably non-zero), and do a
`type echo` from within a script executed in the same way (probably
"shell builtin").
If so, there's your difference.
Yes, this does seem to be my problem. However I didn't know about this
feature of builtin echo and, had I known, I wouldn't have needed to ask
the question.
Here's something else where they explicity use /bin/echo in preference
to bash builtin echo
https://unix.stackexchange.com/questions/522929/check-if-named-pipe-is-open-for-reading
The first answer:
You cannot use the built-in echo (even in a subshell) because the
SIGPIPE will be either caught or kill the whole shell.
