|Anonymous | Login||2020-01-26 20:30 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000621||[1003.1(2008)/Issue 7] Shell and Utilities||Objection||Clarification Requested||2012-10-11 18:55||2020-01-09 06:32|
|Reporter||Don Cragun||View Status||public|
|User Reference||trap on 0 or EXIT|
|Section||trap special built-in utility|
|Final Accepted Text|
|Summary||0000621: Ambiguos requirements for trap on EXIT|
The description of the behavior required for the trap special built-in utility when one of the condition operands is 0 (or equivalently EXIT) is:
The condition can be EXIT, 0 (equivalent to EXIT), or a signal specified using a symbolic name, without the SIG prefix, as listed in the tables of signal names in the <signal.h> header defin ed in XBD Chapter 13 (on page 219); for example, HUP, INT, QUIT, TERM. Implementations may permit names with the SIG prefix or ignore case in signal names as an extension. Setting a trap for SIGKILL or SIGSTOP produces undefined results.
but the text never defines what constitutes an EXIT condition. Logically it could either be process termination or it could be as a result of calling the exit special built-in utility or "falling off the end" of a shell script.
If you interpret EXIT to mean process termination, then the shell is required to perform trap on EXIT actions when the shell is terminated by a SIGKILL signal (which, since it can't catch a SIGKILL, can't happen). If you interpret EXIT to mean calling the exit special built-in or falling off the end of a script, the shell wouldn't be allowed to perform actions associated with an EXIT condition if the shell catches a SIGINT or SIGTERM signal. The shells I have tried do perform actions associated with 0 and EXIT conditions when the shell quits due to receipt of either of these signals; and some otherwise conforming shell scripts depend on this behavior.
Add normative text specifying the conditions under which a condition operand of 0 or EXIT executes the action when the shell terminates. I can't provide exact text because I don't know all of the details, but I would expect it to be something like adding the following text as a new paragraph in the DESCRIPTION after P2368, L74870:
The EXIT condition shall occur when the exit special built-in utility is invoked, the shell reaches the end of input of a command stream being read, or a signal that the shell is catching that will cause the shell to terminate is caught. The shell shall catch any signal other than SIGKILL and SIGSTOP with a trap action that is not '-' from the following list: SIGABRT, SIGALRM, SIGHUP, SIGINT, SIGQUIT, and SIGTERM. Other signals not explicitly ignored in the current shell execution environment may also be caught by and cause the shell to terminate after performing trap on EXIT actions if the default action for that signal as specified by the table in the DESCRIPTION of <signal.h> (see XREF to XBD <signal.h> on page 330) or other implementation provided signals would cause abnormal termination of the shell.
|Tags||No tags attached.|
1. If the shell is waiting for the completion of a utility executing a foreground command, it does not take traps set on signals until the foreground command has completed. Is it intended that the EXIT trap is taken immediately when a signal is received?
2. If the signal handler for SIGABRT just sets a flag and returns (likely, because executing trap commands is not async-signal-safe), it will not affect abort(). This is how it should be (because the state of the program is unsafe) but naive people may expect differently.
I am searching for issues related to traps, and came across this one which
seems to have fallen into a crack somewhere...
I am also not sure what the issue is really - if a shell is catching SIGINT
(etc) then either it executes a trap 'action' INT action, in which case what
happens depends upon what the action does (if it does an exit, then the EXIT
trap should be taken, otherwise not) - if there's no trap, but the shell
catches the signal anyway (which can be useful) then either the shell exits
on SIGINT (in which case it should run the EXIT trap) or it doesn't (and
obviously no EXIT trap)
What's in the proposed wording makes no sense to me,there is nothing nearly
as complicated as it suggests - if the shell exits it runs the EXIT trap (if
one is set for that shell). It really is, or should be, that simple. If
wording is needed to make it clear that this happens when the shell decides
to exit, rather than being killed by SIGKILL or some other signal that causes
termination, then just say that, no need to list signal names that do one
thing or another.
I also don't see what is relevant about how the shell runs trap handlers, or
when (for this issue) - simply, if the shell decides to exit 9no matter why)
and there is an EXIT trap set, that trap is run. The "decides" is what
matters, being killed is not deciding, it simply happens - no trap in that
case (which includes when a script sets a timer, which delivers a signal
that has not been arranged to be caught - even though the shell, in some
sense, has decided to exit (when the timer elapses) it did not actually
decide to exit at the instant the signal was delivered - so no trap.
I've tested and examined the default sh implementation on FreeBSD 12.1-RELEASE-p1, the EXIT trap isn't invoked when SIGINT is sent.
$ cat > trap.sh << EOF
trap 'echo yes' EXIT
$ chmod +x trap.sh
$ ./trap.sh # wait for it to sleep 10 seconds.
$ uname -a
Re Note: 0004712
I ran that test on all the shells I normally test, only mksh and bash
run the trap on the SIGINT exit, all the others (dash, bosh, yash, zsh,
pdksh, nbsh, and as you noted, fbsh, did not). (They all do for the normal
exit case of course).
I don't really expect (nor should we encourage) a shell to catch signals
just so it can invoke an exit trap if the signal happens to cause the
shell to exit.
What would you expect if the signal were SIGKILL rather than SIGINT ?
Perhaps we need some words to differentiate "exit" (which is the shell
deciding it is done - for any reason) from being killed externally.
edited on: 2020-01-09 06:37
Note that the proposed resolution affects only signals that are
being trapped (not those being ignored, which do nothing obviously
and so do not cause an exit, or those at SIG_DFL (trap - SIGxxx)).
My comment in Note: 0004130 was because if such a signal handler
causes the shell to exit, then that is just "exit" the command,
and the fact that it was issued from a trap handler is really
irrelevant, if the shell runs the exit command (or reaches EOF
on stdin) then it exits, and in those cases the EXIT trap runs.
In other cases, it normally does not (and arguably should not).
That a shell happens to need (for whatever reason) to catch a
signal that the script has not trapped, and after doing whatever
it needs to do (eg: restoring terminal modes) exits (either by
exit(), or by resetting the signal handler to SIG_DFL and then
sending that signal to itself) should not be running the EXIT
trap, which the script was not expecting to happen in that case
(nor in the case of a signal which the shell does not, or cannot,
catch, but which nevertheless kills the shell).
|2012-10-11 18:55||Don Cragun||New Issue|
|2012-10-11 18:55||Don Cragun||Status||New => Under Review|
|2012-10-11 18:55||Don Cragun||Assigned To||=> ajosey|
|2012-10-11 18:55||Don Cragun||Name||=> Don Cragun|
|2012-10-11 18:55||Don Cragun||Organization||=> Self|
|2012-10-11 18:55||Don Cragun||User Reference||=> trap on 0 or EXIT|
|2012-10-11 18:55||Don Cragun||Section||=> trap special built-in utility|
|2012-10-11 18:55||Don Cragun||Page Number||=> 2368|
|2012-10-11 18:55||Don Cragun||Line Number||=> 74866-74870|
|2012-10-11 18:55||Don Cragun||Interp Status||=> ---|
|2012-11-06 12:01||jilles||Note Added: 0001416|
|2018-09-28 01:43||kre||Note Added: 0004130|
|2020-01-09 05:10||dannyniu||Note Added: 0004712|
|2020-01-09 06:25||kre||Note Added: 0004713|
|2020-01-09 06:32||kre||Note Added: 0004714|
|2020-01-09 06:37||kre||Note Edited: 0004714|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|