View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000053 | 1003.1(2008)/Issue 7 | Shell and Utilities | public | 2009-06-25 13:46 | 2013-04-16 13:06 |
| Reporter | geoffclare | Assigned To | ajosey | ||
| Priority | normal | Severity | Objection | Type | Error |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Geoff Clare | ||||
| Organization | The Open Group | ||||
| User Reference | |||||
| Section | 2.14 | ||||
| Page Number | 2368 | ||||
| Line Number | 74879 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | 0000053:0000094 | ||||
| Summary | 0000053: trap in a subshell | ||||
| Description | The description of the trap utility states: When a subshell is entered, traps that are not being ignored are set to the default actions. It then goes on to state requirements about the output of trap with no arguments, including the example: save_traps=$(trap) ... eval "$save_traps" However, in this example when trap is executed in the command substitution it is in a subshell, and therefore (according to the first quote above) $save_traps will not include traps that are not being ignored. The eval will only restore the traps being ignored. This does not match existing practice: the example "works" in current shells. However, they seem to use two different solutions. Most shells try to decide whether the purpose of the command substitution is to query the current traps, and if so they don't alter the traps. However, they are not very good at it - things like: var=trap; save_traps=$($var) or even: save_traps=$(trap; true) don't work. The other solution (used only by ksh93 out of the shells I tried) is that a trap command without operands in a subshell doesn't report the current traps - it reports the traps that were in effect immediately before the current subshell environment was entered, unless a trap command with operands has subsequently been executed. Both solutions have disadvantages. The first, as can be seen from the examples above, may give the wrong output in cases other than a straight $(trap) or `trap`. The second gives misleading output when trying to report the current trap settings from within a subshell (although saving them to a variable in a subshell works because trap in the lower subshell reports the traps that were in effect in the higher subshell). In both cases the number of applications affected is likely to be very small. (With the second, the problem doesn't so much affect the applications themselves as application writers trying to debug the trap handling in their scripts.) There are several ways this could be fixed in the standard: 1. Allow both solutions. (Making the standard match existing practice.) 2. Allow the first solution only. (Making the standard match existing practice on certified systems.) 3. Allow the second solution only. (Eliminating the dubious practice of trying to identify when a command substitution is being used to query the current traps.) 4. Require something else, such as a precise specification of the detection performed in the first solution, or a variation of the second solution where it only applies to command substitutions not to all subshells. 5. As 1, 2 or 3 but also add in FUTURE DIRECTIONS that a future revision may require 4. Wording changes are proposed below for options 1, 2 and 3. They also include a minor fix changing "no arguments" to "no operands". Finally, a warning to anyone who wishes to investigate the behaviour of ksh93: ensure you don't end your test script with the subshell you are testing. Follow it with another command such as "echo done". Otherwise, ksh93 uses an optimisation whereby it doesn't set up the subshell environment, and this alters the results. (My thanks to David Korn for pointing this out to me. He also acknowledged that the effect of this optimisation on traps is a bug in ksh93.) | ||||
| Desired Action | Option 1: Change "When a subshell is entered, traps that are not being ignored are set to the default actions." to "When a subshell is entered, traps that are not being ignored shall be set to the default actions, except in the case of a command substitution containing only a single trap command, when the traps need not be altered. Implementations may check for this case using only lexical analysis; for example if `trap` and $( trap -- ) do not alter the traps in the subshell, cases such as assigning var=trap and then using $($var) may still alter them." Change "The trap command with no arguments shall write to standard output a list of commands associated with each condition." to "The trap command with no operands shall write to standard output a list of commands associated with each condition. If the command is executed in a subshell, the implementation does not perform the optional check described above for a command substitution containing only a single trap command, and no trap commands with operands have been executed since entry to the subshell, the list shall contain the commands that were associated with each condition immediately before the subshell environment was entered. Otherwise, the list shall contain the commands currently associated with each condition." Option 2: Change "When a subshell is entered, traps that are not being ignored are set to the default actions." to "When a subshell is entered, traps that are not being ignored shall be set to the default actions, except in the case of a command substitution containing only a single trap command, when the traps shall not be altered. Implementations may check for this case using only lexical analysis; for example `trap` and $( trap -- ) are required not to alter the traps in the subshell, whereas if the assignment var=trap has previously been made, $($var) may alter them." Change "The trap command with no arguments shall write ..." to "The trap command with no operands shall write ..." Option 3: Change "The trap command with no arguments shall write to standard output a list of commands associated with each condition." to "The trap command with no operands shall write to standard output a list of commands associated with each condition. If the command is executed in a subshell and no trap commands with operands have been executed since entry to the subshell, the list shall contain the commands that were associated with each condition immediately before the subshell environment was entered. Otherwise, the list shall contain the commands currently associated with each condition." | ||||
| Tags | tc1-2008 | ||||
|
|
Originally reported by gwc:xxxxxxxxxxxxx Thu, 19 Mar 2009 11:15:35 +0000 with Subject: Defect in XCU 2.14 trap Transcribed by Don Cragun from xcubug3.txt ERN 9 Submitter tag "gwc trap in subshell" |
|
|
Interpretation response ------------------------ The standard states the requirements for trap in a subshell, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor." Rationale: ------------- None. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Apply Option 1 from the submitters suggested changes |
|
|
A related issue is whether subshells are supposed to inherit the set of jobs known to the parent, or if creating a subshell empties the set of asynchronous jobs known to the current shell environment within that subshell. In other words, given that a pipe can but not must be executed in a subshell, should 'sleep 5& jobs | head -n1' always be silent, always describe the sleep, or be dependent on whether the shell executes pipelines in a subshell and/or whether the use of jobs within a subshell is recognized as an attempt to learn about jobs from the parent rather than the set of jobs managed solely by that subshell. Also, there are some shells like pdksh where 'set -m; echo $-; (echo $-)' gives different output between the two lines (the subshell loses the m), although I believe the standard is clear that this is a bug. |
|
|
Set Interp Required; also regarding 0000053:0000160 - this should properly be the topic of a new bug and not considered as part of this one. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-06-25 13:46 | Don Cragun | New Issue | |
| 2009-06-25 13:46 | Don Cragun | Status | New => Under Review |
| 2009-06-25 13:46 | Don Cragun | Assigned To | => ajosey |
| 2009-06-25 13:46 | Don Cragun | Name | => Geoff Clare |
| 2009-06-25 13:46 | Don Cragun | Organization | => The Open Group |
| 2009-06-25 13:46 | Don Cragun | Section | => 2.14 |
| 2009-06-25 13:46 | Don Cragun | Page Number | => 2368 |
| 2009-06-25 13:46 | Don Cragun | Line Number | => 74879 |
| 2009-06-25 13:50 | Don Cragun | Note Added: 0000093 | |
| 2009-06-25 13:53 | Don Cragun | Note Added: 0000094 | |
| 2009-06-25 13:53 | Don Cragun | Reporter | Don Cragun => geoffclare |
| 2009-06-25 13:53 | Don Cragun | Status | Under Review => Resolved |
| 2009-06-25 13:53 | Don Cragun | Resolution | Open => Accepted As Marked |
| 2009-06-25 16:38 | Don Cragun | Tag Attached: real bug in aardvark | |
| 2009-06-26 06:25 | Don Cragun | Note Edited: 0000093 | |
| 2009-06-26 08:51 | Don Cragun | Final Accepted Text | => Note 0000094 |
| 2009-06-26 09:32 | Don Cragun | Final Accepted Text | Note 0000094 => 0000053:0000094 |
| 2009-07-13 13:19 | eblake | Note Added: 0000160 | |
| 2009-07-30 16:11 | msbrown | Tag Detached: real bug in aardvark | |
| 2009-07-30 16:13 | msbrown | Note Added: 0000169 | |
| 2009-07-30 16:13 | msbrown | Status | Resolved => Interpretation Required |
| 2009-08-11 16:24 | Don Cragun | Interp Status | => --- |
| 2009-08-11 16:25 | Don Cragun | Interp Status | --- => Pending |
| 2009-09-17 15:41 | nick | Interp Status | Pending => Proposed |
| 2009-10-09 16:24 | ajosey | Note Edited: 0000094 | |
| 2009-10-09 16:25 | ajosey | Note Edited: 0000094 | |
| 2009-10-09 16:25 | ajosey | Interp Status | Proposed => Approved |
| 2010-09-20 09:07 | geoffclare | Tag Attached: tc1-2008 | |
| 2011-05-13 15:38 | eblake | Relationship added | related to 0000440 |
| 2011-05-13 15:40 | eblake | Relationship added | has duplicate 0000268 |
| 2013-04-16 13:06 | ajosey | Status | Interpretation Required => Closed |
