0000053: trap in a subshell - Austin Group Defect Tracker

Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details [ Jump to Notes ]

[ Issue History ] [ Print ]

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	0000268	Closed	ajosey	1003.1(2004)/Issue 6	trap with no arguments
related to	0000440	Closed	ajosey	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[^]