View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000751 | 1003.1(2013)/Issue7+TC1 | Shell and Utilities | public | 2013-09-17 15:10 | 2019-06-10 08:55 |
| Reporter | geoffclare | Assigned To | |||
| Priority | normal | Severity | Comment | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted | ||
| Name | Geoff Clare | ||||
| Organization | The Open Group | ||||
| User Reference | |||||
| Section | 2.11 | ||||
| Page Number | 2353 | ||||
| Line Number | 74957 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | 0000751:0001859 | ||||
| Summary | 0000751: Using trap to reset SIGINT/QUIT in an asynchronous subshell | ||||
| Description | Several current shells have a feature/bug, which seems to be the result of historical accident, whereby they silently ignore attempts to use trap to set SIGINT or SIGQUIT to the default action or to set a trap for them after they have been set to be ignored by the shell when it executes an asynchronous subshell (and job control is disabled). For example, if a script containing the following is run in the foreground at a terminal: (trap - INT; exec sleep 10) & wait and is then terminated by typing the interrupt character, in these shells the sleep does not get the signal and continues running in the background. I would like clarification that this behaviour is not allowed by the standard and should be considered a bug in the shells that do it. The behaviour seems to have no benefit at all, and prevents shell script authors from executing multiple subshells in parallel and making them interruptible (which is desirable if the script is going to wait for them). Note that this behaviour has no connection with the following statement in the description of trap: Signals that were ignored on entry to a non-interactive shell cannot be trapped or reset, although no error need be reported when attempting to do so. which applies only on entry to the shell itself, not on entry to a subshell. Nor is it due to a misinterpretation of this text as applying to subshells, since it does not happen in the affected shells if trap is used to ignore SIGINT before executing a (non-asynchronous) subshell, as in: trap "" INT; (trap - INT; exec sleep 10) | ||||
| Desired Action | 1. Issue a "standard is clear; standard is right" interpretation. 2. Add some rationale about the issue in XRAT... After page 3700 line 126619 section C.2.11 add a new first paragraph: Historically, some shell implementations silently ignored attempts to use trap to set SIGINT or SIGQUIT to the default action or to set a trap for them after they have been set to be ignored by the shell when it executes an asynchronous subshell (and job control is disabled). This behavior is not conforming. For example, if a shell script containing the following line is run in the foreground at a terminal: (trap - INT; exec sleep 10) & wait and is then terminated by typing the interrupt character, this standard requires that the sleep command is terminated by the SIGINT signal. | ||||
| Tags | tc2-2008 | ||||
| related to | 0000750 | Closed | Async list handling of SIGINT and SIGQUIT depends on job control |
|
|
Interpretation response ------------------------ The standard clearly states that shells must allow attempts to use trap to set SIGINT or SIGQUIT to the default action in these situations, and conforming implementations must conform to this. Rationale: ------------- This is what the specification requires. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Follow the actions specified in the "Desired Action" section above. |
|
|
Yes, they can be set but, given #750, they're not going to be delivered from a keyboard event unless it's a foreground process, and using '&' makes them a background process where stdin isn't connected to a keyboard. Was it discussed adding that ')' can have a '<' redirection that applies to the '&' operator also, so the conditions for delivery could be explicitly set and override the default behavior? |
|
|
The redirection of stdin caused by use of '&' has no relevance to this issue. The keyboard-generated signals are produced by the General Terminal Interface regardless of whether stdin is connected to the terminal or redirected from elsewhere. Try this command in a conforming shell and you will find that you can interrupt the sleep just fine: sleep 10 < /dev/null Also, in a non-interactive shell, job control is disabled by default. When a shell script containing: (trap - INT; exec sleep 10) & wait is run in the foreground at a terminal, the sleep is in the foreground process group and a SIGINT is delivered to it when the interrupt character is typed - the only issue is whether or not it ignores the signal. |
|
|
XBD 11.1.3, Line 6559+ has language that child processes of a session may be orphaned from their controlling terminal reference when all explicit opens or inheritance of the terminal device are closed. The only way for applications to make sure they're not orphaned is to keep the inherited dup of stdin, where applicable, or explicitly opening /dev/tty/ to another file handle so at least one process has it open. It's an unlikely situation for most implementations, granted, but if all children redirect to /dev/null/ and the session leader that established the only open of the terminal device dies it's not impossible either. This implies to me that an active connection to, not just inheritance of, a controlling terminal impacts to an extent whether signals should be delivered. The text of XBD 11.1.4 doesn't have the other signals, TTIN and TTOU, being attempted until a read or write after open makes them plausible in a background process. Processes that aren't connected to a FIFO or socket don't expect to receive signals about their events either, that I can see. Where the language is ambiguous is more on how a foreground or background job process group that inherited an open connection is supposed to reraise it to subprocesses and subgroups that don't have the terminal open because of piping, or raise SIGKILL instead. I don't see that all or nothing cuts it, based just on controlling process group, but that's for another ERN. As to the second example, the language of XCU 2.9 supports that an implementation can require all simple commands or command lists used with '&' to have their own separate process group to be assigned job_ids for reporting by the jobs utility. The shell the example was tested on appears not to do this. When job control is active (see set -b) this is more required than optional, it looks. The subshell environments forked for each command of the list would belong to that group, not the foreground terminal group, which is why I consider going to the background this way significant. I did abbreviate it though, in the above. Doing it this way keeps the 'known process ids' all of one type, not that some refer to single processes and some refer to command list groups; they're all group ids. I can see that the language also supports the behavior described, somewhat, but I don't see it as definitive that an implementation is required to deliver the signals in those situations. XCU 2.9.4 also answers the redirect question; line 74545 says ')' is supposed to be able to take a '<& 0' pipe. |
|
|
Interpretation Proposed 21 Feb 2014 |
|
|
Interpretation Approved: 25 March 2014 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-09-17 15:10 | geoffclare | New Issue | |
| 2013-09-17 15:10 | geoffclare | Name | => Geoff Clare |
| 2013-09-17 15:10 | geoffclare | Organization | => The Open Group |
| 2013-09-17 15:10 | geoffclare | Section | => 2.11 |
| 2013-09-17 15:10 | geoffclare | Page Number | => 2353 |
| 2013-09-17 15:10 | geoffclare | Line Number | => 74957 |
| 2013-09-17 15:10 | geoffclare | Interp Status | => --- |
| 2013-09-17 15:11 | geoffclare | Relationship added | related to 0000750 |
| 2013-10-03 16:22 | msbrown | Interp Status | --- => Pending |
| 2013-10-03 16:22 | msbrown | Note Added: 0001859 | |
| 2013-10-03 16:22 | msbrown | Status | New => Interpretation Required |
| 2013-10-03 16:22 | msbrown | Resolution | Open => Accepted |
| 2013-10-03 16:23 | msbrown | Final Accepted Text | => 0000751:0001859 |
| 2013-10-03 16:23 | msbrown | Tag Attached: tc2-2008 | |
| 2013-10-03 16:25 | msbrown | Note Edited: 0001859 | |
| 2013-10-04 08:52 | shware_systems | Note Added: 0001860 | |
| 2013-10-04 12:17 | geoffclare | Note Added: 0001861 | |
| 2013-10-06 01:45 | shware_systems | Note Added: 0001862 | |
| 2014-02-21 15:40 | ajosey | Interp Status | Pending => Proposed |
| 2014-02-21 15:40 | ajosey | Note Added: 0002156 | |
| 2014-03-25 13:44 | ajosey | Interp Status | Proposed => Approved |
| 2014-03-25 13:44 | ajosey | Note Added: 0002207 | |
| 2019-06-10 08:55 | agadmin | Status | Interpretation Required => Closed |
