Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
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 2024-06-11 08:52
Reporter Don Cragun View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Don Cragun
Organization Self
User Reference trap on 0 or EXIT
Section trap special built-in utility
Page Number 2368
Line Number 74866-74870
Interp Status ---
Final Accepted Text Note: 0005938
Summary 0000621: Ambiguos requirements for trap on EXIT
Description 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.
Desired Action 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 tc3-2008
Attached Files

- Relationships

-  Notes
(0001416)
jilles (reporter)
2012-11-06 12:01

 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.
(0004130)
kre (reporter)
2018-09-28 01:43

 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.
(0004712)
dannyniu (reporter)
2020-01-09 05:10

 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
#!/bin/sh
trap 'echo yes' EXIT
sleep 10
EOF
$ chmod +x trap.sh
$ ./trap.sh
^C
$ ./trap.sh # wait for it to sleep 10 seconds.
yes
$ uname -a
FreeBSD ...
```
(0004713)
kre (reporter)
2020-01-09 06:25

 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.
(0004714)
kre (reporter)
2020-01-09 06:32
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).
(0005938)
geoffclare (manager)
2022-08-22 15:54

 After 2018 edition page 2420 line 77499 section 2.14 trap, add a new paragraph:
The EXIT condition shall occur when the shell terminates normally (exits), and may occur when the shell terminates abnormally as a result of delivery of a signal (other than SIGKILL) whose trap action is the default.

- Issue History
Date Modified Username Field Change
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
2022-05-31 23:29 psmith Issue Monitored: psmith
2022-08-22 15:54 geoffclare Note Added: 0005938
2022-08-22 15:54 geoffclare Final Accepted Text => Note: 0005938
2022-08-22 15:54 geoffclare Status Under Review => Resolved
2022-08-22 15:54 geoffclare Resolution Open => Accepted As Marked
2022-08-22 15:55 geoffclare Tag Attached: tc3-2008
2022-09-27 15:23 geoffclare Status Resolved => Applied
2024-06-11 08:52 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker