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. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”