Dash: How to capture output of trap (invoked w/o arguments)

dashtrap:

The section on trap in the dash manpage states the following:

trap without any arguments cause it to write a list of signals and their associated action to the standard output in a format that is suitable as an input to the shell that achieves the same trapping results.

Awesome! I thought I'd found an easy way to reinstate previous signal handlers that I've overridden, by feeding trap's output back to the shell as a command:

trap "echo 'good'" EXIT

# save signal handlers to $traps
traps="$(trap)"

# override EXIT handler
trap "echo 'bad'" EXIT

# reinstate original handlers
eval "$traps"

Desired output: good

Actual output: bad

And that's completely logical because $traps is empty, which is in turn consistent with the manpage:

When the shell forks off a subshell, it resets trapped (but not ignored) signals to the default action.

(The command substitution $(trap) forks off a subshell, so trap doesn't know about any signal handlers.)

Everything seems to behave as it should. But how do I take advantage of trap's list functionality?

Best Answer

You can redirect to a temp file:

file=$(mktemp) || exit
{
  rm -f -- "$file"
  trap
  traps=$(cat)
} > "$file" < "$file"

Note that in that regard dash's trap is not POSIX as POSIX does require that:

var=$(trap)

be treated as a special case where the traps are not reset in the subshell.

zsh and mksh also have the issue. In zsh however, you can do:

trap | IFS= read -rd '' traps

Related Solutions

Bash – exit trap in dash vs ksh and bash

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.

Best Answer

Related Solutions

Bash – exit trap in dash vs ksh and bash

Related Question