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
0000751 [1003.1(2013)/Issue7+TC1] Shell and Utilities Comment Clarification Requested 2013-09-17 15:10 2019-06-10 08:55
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Closed  
Name Geoff Clare
Organization The Open Group
User Reference
Section 2.11
Page Number 2353
Line Number 74957
Interp Status Approved
Final Accepted Text Note: 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
Attached Files

- Relationships
related to 0000750Closed Async list handling of SIGINT and SIGQUIT depends on job control 

-  Notes
(0001859)
msbrown (manager)
2013-10-03 16:22
edited on: 2013-10-03 16:25

 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.
(0001860)
shware_systems (reporter)
2013-10-04 08:52

 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?
(0001861)
geoffclare (manager)
2013-10-04 12:17

 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.
(0001862)
shware_systems (reporter)
2013-10-06 01:45

 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.
(0002156)
ajosey (manager)
2014-02-21 15:40

 Interpretation Proposed 21 Feb 2014
(0002207)
ajosey (manager)
2014-03-25 13:44

 Interpretation Approved: 25 March 2014

- Issue History
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 => Note: 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

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