14

Here's a simple script that sets up a temp dir in the current dir and a trap to delete it on exit.

#filename: script   
set -x  
trap 'rm -rf "$d"' exit
d=`TMPDIR=$PWD mktemp -d`
"$@"

If I do ksh script sleep 100 or bash script sleep 100 and interrupt it with, C-C, the trap gets executed and the directory is deleted. It doesn't work with dash. Why? Is this a bug or intended behavior?

Petr Skocik
  • 28,816

2 Answers2

21

zsh, pdksh (though not recent versions of mksh derived from that), yash, the Bourne shell behave like dash.

Only bash, ksh88, ksh93 and mksh behave otherwise.

The POSIX spec is not clear on what should be the correct behaviour, but there's nothing in there that says that the shell is allowed to override the default handler for the SIGINT (or other) signal.

It says EXIT trap action should be evaluated when exit is invoked, but AFAICT, it doesn't even say for instance if it should be evaluated when the shell exits as the result of set -e or set -u or error conditions like syntax errors or failing special builtins.

To be able to run EXIT trap upon reception of a signal, the shell would need to install a handler on that signal.

That's what ksh, mksh and bash do, but the list of signals they handle is different between all three implementations. The only signals common between all 3 seem to be INT, QUIT, TERM, ALRM and HUP.

If you want the EXIT trap to be run upon some signals, the portable way would be to handle those signals yourself:

trap 'exit 1' INT HUP QUIT TERM ALRM USR1
trap 'cleanup' EXIT

That approach however doesn't work with zsh, which doesn't run EXIT trap if exit is called from a trap handler.

It also fails to report your death-by-signal to your parent.

So instead, you could do:

for sig in INT QUIT HUP TERM ALRM USR1; do
  trap "
    cleanup
    trap - $sig EXIT
    kill -s $sig "'"$$"' "$sig"
done
trap cleanup EXIT

Now, beware though that if more signals arrive while you're executing cleanup, cleanup may be run again. You may want to make sure your cleanup works correctly if invoked several times and/or ignore signals during its execution.

pevik
  • 1,463
  • 17
  • 28
Stéphane Chazelas
  • 544,893
  • zsh only behave like dash in non-interactive session, it does the same as bash and ksh in interactive session. – cuonglm Nov 04 '15 at 13:26
  • Nice solution! If I understand it correctly then it even preserves the special exit status codes of the different signals. – phk Nov 04 '15 at 14:24
  • 1
    Stéphane, is a process killing itself with the received signal (kill -s $sig "'"$$"' "$sig" above) a best practice in general, or is it only applicable with SIGINT (as seen at section 5 at SignalTrap ) – iruvar Nov 11 '18 at 03:41
  • 1
    @iruvar, it's especially important for SIGINT and SIGQUIT as otherwise you'll have troubles if your script is called from a shell that implements that "wait and cooperative exit" approach discussed as that page (which I've amended slightly), but it's a good idea to do it as well for other signals if only to report to your parent that you have been killed. – Stéphane Chazelas Nov 11 '18 at 22:01
  • @StéphaneChazelas What is the purpose of the trailing EXIT in trap - $sig EXIT line? It is the only point where your answer diverges from the wooledge bash guide – Harold Fischer Mar 29 '19 at 04:10
  • 1
    @HaroldFischer, that resets the EXIT trap which avoids cleanup being run twice upon signal delivery for shells like mksh or ksh93. – Stéphane Chazelas Mar 29 '19 at 08:41
  • @StéphaneChazelas "You may want to make sure your cleanup works correctly if invoked several times and/or ignore signals during its execution." How might I make cleanup ignore signals during it's execution? Would this need to be implemented inside the trap that calls cleanup or within cleanup itself? – Harold Fischer Nov 27 '19 at 05:21
  • "That approach however doesn't work with zsh, which doesn't run the EXIT trap if exit is called from a trap handler." In contradiction zsh 5.7.1 seems to run EXIT trap, but dash 0.5.10.2-6 does not, if -e is used. – jarno Jul 06 '20 at 10:25
  • Thanks @jarno, yes it looks like it changed in newer versions of zsh. Do you know which version introduced the change? – Stéphane Chazelas Jul 06 '20 at 10:32
  • Unfortunately no – jarno Jul 06 '20 at 10:37
  • Why do you use single quoting in the kill command? – jarno Oct 24 '20 at 10:16
  • @jarno, so "$$" be passed literally to the trap command so the code of the trap be something like cleanup; trap - INT EXIT; kill -s INT "$$" – Stéphane Chazelas Oct 24 '20 at 10:41
  • I think it is unneeded because the value of $$ does not change within the script, if I have understood correctly. – jarno Oct 24 '20 at 11:22
  • Yes, the code of the trap could be cleanup; trap - INT EXIT; kill -s INT 1234 (where 1234 is the value of $$ at the time trap was invoked and as you say shouldn't change). While both are equally valid, the output of trap in the former case is better as it conveys the intention and can be reused in a context where $$ is different. – Stéphane Chazelas Oct 24 '20 at 11:26
  • BTW, if you called a script in a wrapper script how would you test death-by-signal of the script in the wrapper script a.k.a parent? – jarno Oct 24 '20 at 11:26
  • @jarno, depends what language the wrapper script is written in. For instance, many shells can't distinguish a death by signal 1 from a exit(129). See Default exit code when process is terminated? – Stéphane Chazelas Oct 24 '20 at 11:30
  • Oh, so by the exit code. I thought the signal would propagate to the caller so I tried to detect it by a trap in the parent Bash script but it did not work. – jarno Oct 24 '20 at 11:38
1

Warning: exit is not guaranteed to work, you should instead use EXIT

Given that the POSIX standard does not define whether the EXIT trap should also be executed in case of a signal and given the fact that the Bourne Shell does not call the EXIT trap in the case you mention, it is obvious that you are entering unspecified behavior.

spiralofhope
  • 109
schily
  • 19,173