Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000053 [1003.1(2008)/Issue 7] Shell and Utilities Objection Error 2009-06-25 13:46 2013-04-16 13:06
Reporter geoffclare View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Geoff Clare
Organization The Open Group
User Reference
Section 2.14
Page Number 2368
Line Number 74879
Interp Status Approved
Final Accepted Text Note: 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
Attached Files

- Relationships
has duplicate 0000268Closedajosey 1003.1(2004)/Issue 6 trap with no arguments 
related to 0000440Closedajosey 2008-TC1 XCU/TC1/D1/0035 redundant 

-  Notes
(0000093)
Don Cragun (manager)
2009-06-25 13:50
edited on: 2009-06-26 06:25

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"

(0000094)
Don Cragun (manager)
2009-06-25 13:53
edited on: 2009-10-09 16:25

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

(0000160)
eblake (manager)
2009-07-13 13:19

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.
(0000169)
msbrown (manager)
2009-07-30 16:13

Set Interp Required; also regarding Note: 0000160 - this should properly be the topic of a new bug and not considered as part of this one.

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


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