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
0001211 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Clarification Requested 2018-09-28 02:22 2024-06-11 09:08
Reporter kre View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Robert Elz
Organization
User Reference
Section XCU 2.14 -- trap special builtin
Page Number 2420
Line Number 77514 - 77526
Interp Status ---
Final Accepted Text Note: 0004355
Summary 0001211: "trap" (with no args) specification does not match reality
Description I kind of brlieve I have seen this somewhere before, but cannot find it if
it exists already, if so, and if this contains nothing new,just close it...

The trap command description states:

      The trap command with no operands shall write to standard output a list
      of commands associated with each condition. If the command is executed
[ what follows is not relevant to the issue in question ]
      Otherwise, the list shall contain the commands currently associated
      with each condition.
[ then follows the format to be used, also not relevant here ]

      The shell shall format the output, including the proper use of quoting,
[ not relevant here, but let's keep that bit ]
      so that it is suitable for reinput to the shell as commands that
      achieve the same trapping results. For example:

          save_traps=$(trap)
          ...
          eval "$save_traps"

If only it were so, but there neither is, nor ever has been, a shell that
acts like that.

for f in sh yash zsh bash mksh fbsh bosh ksh mksh dash
do
       echo "$f: $( $f -c 'X=$(trap); echo "$x"' )"
done | sort
bash:
bosh:
dash:
fbsh:
ksh:
mksh:
mksh:
sh:
yash:
zsh:

(the "sort" is just because I couldn't be bothered to generate the list
in a sane order...) sh is NetBSD, fbsh is FreeBSD, ksh is pdksh (right
now I do not have access to ksh93, but it acts the same.)

Shells only list traps that have been altered from the default in the
output from the "trap" command. This makes it useless for the intended
effect, as if a piece of code does

     saved_traps=$(trap)
     trap '' INT
     # do some code with SIGINT ignored (that works fine)
     eval "${saved_traps}"

then one would expect, from the wording in the standard, that after the
eval, the action for SIGINT would be back to what it was when the
saved_traps= line was executed. In *every* existing shell that happens
only when an INT trap had been set before this code (of if it had been
ignored, but then it would not be interesting).

I will be submitting an enhancement request as a separate issue to actually
provide a mechanism that does work, but that isn't appropriate here, the best
we can to for tc8 is to correct this wording so it is not nonsense...
(however nice it would be if the nonsense were reality.)
Desired Action Change the sentence starting on line 77514 from

      The trap command with no operands 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 which is not in its default
      state.

Change the sentence at line 77522 from

      The shell shall format the output, including the proper use of quoting,
      so that it is suitable for reinput to the shell as commands that
      achieve the same trapping results for those traps that had previously
      been altered.

And also change the example at lines 77524-6 from

      save_traps=$(trap)
      ...
      eval "$save_traps"

to

      save_traps=$(trap)
      ...
      for sig in EXIT $( kill -l )
      do
          case "$sig" in
          SIGKILL | KILL | sigkill | kill | SIGSTOP | STOP | sigstop | stop)
                   ;;
          *) trap - $sig
                   ;;
          esac
      done
      eval "$save_traps"

(and don't add these words, but yes, that is absurd, there needs to be
a better way, but pretending that it works as is, or that shells will ever
be altered to make the current description work, is not it)

On page 2423, line 77606 (FUTURE DIRECTIONS) change
      None.
to
      A mechanism to obtain the current setting of all traps (including
      those still in their default states) has been propopsed and is
      expected to be included in a future version of this standard.

(or whatever the correct wording is to make that clear - including a
reference to the issue which proposes it, coming soon, if that is appropriate.)
Tags tc3-2008
Attached Files

- Relationships
related to 0001212Closed Enhance trap command 

-  Notes
(0004132)
kre (reporter)
2018-09-28 03:23

 In the description, the "echo $x" should obviously be "echo $X"
(or it should be x= instead of X= ... that's a transcription error,
it makes no difference to the result.
(0004133)
geoffclare (manager)
2018-09-28 08:44
edited on: 2018-09-28 09:04

 The behaviour of $(trap) was investigated in depth in 2009 via bug 0000053

However, the issue of the output being empty when no changes from the default have been made did not come up, so I think that's new.

Rather than the complicated method you propose, I think it would be simpler for applications to do this kind of thing:

save_traps=$(trap)
trap "some command" INT QUIT
save_traps="trap - INT QUIT; $save_traps"

...

eval "$save_traps"
(0004135)
kre (reporter)
2018-09-28 10:25

 First, what is most important here is that it is recognised that
the current wording is inadequate, and promises something that it
is unable to deliver.

The workaround method that can be used can vary, I'm sure there are
many possibilities - your scheme (note 4133) assumes you know in advance
what traps are to be altered, which will often be the case, but is not
suitable for a general solution.

Regardless of that, we need to do something to make it clear that simply
using $(trap) is not sufficient in any current shell as a method of restoring
what was there before.
(0004136)
kre (reporter)
2018-09-28 10:40

 I just realised that I left messed up one of the desired changes
in the Desired action.

The paragraph that begins ...

Change the sentence at line 77522 from

should have the text that is currently there, followed by "to"
(that is, what looks to be intended to be the old text, is in
fact the desired new text...)


Also, wwrt general solutions, if the standard had "trap -" to
reset all traps to their defaults, workaround would be easier.
This may actually exist in more shells than have trap -p, but
I haven't tested it. If we could rely upon that, a workable
solution to this problem would be easier.

Do note though that any solution that resets traps to default, and
then puts them back to their old values suffers from races, when a
signal arrives between the "trap - xxx" (or just "trap -" and when
the eval "$saved_traps" is done, so while they can often be used as
a "good enough" solution, we really do need (eventually) to add
something which really works.
(0004355)
geoffclare (manager)
2019-04-04 16:36

 Change the sentence starting on line 77514 from:
The trap command with no operands 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 which is not in its default state.

Change the sentence at line 77522 from:
The shell shall format the output, including the proper use of quoting, so that it is suitable for reinput to the shell as commands that achieve the same trapping results.
to:
The shell shall format the output, including the proper use of quoting, so that it is suitable for reinput to the shell as commands that achieve the same trapping results for those traps that had previously been altered.

And also change the example at lines 77524-6 from:
save_traps=$(trap)
...
eval "$save_traps"
to:
save_traps=$(trap)
trap "some command" INT QUIT
save_traps="trap - INT QUIT; $save_traps"

...

eval "$save_traps"

On page 2422 line 77564, change APPLICATION USAGE from:
None.
to:
Since trap with no operands does not output commands to restore traps that are currently set to default, these need to be restored separately. The DESCRIPTION section shows one example, but the method it uses relies on hard-coding the commands to reset the traps that are being set. A more general approach would be:
save_traps=$(trap)
...
for sig in EXIT $( kill -l )
do
     case "$sig" in
     SIGKILL | KILL | sigkill | kill | SIGSTOP | STOP | sigstop | stop)
              ;;
     *) trap - $sig
              ;;
     esac
done
eval "$save_traps"

However, this has a race condition since it first sets all traps (that can be set) to default and then restores those that were not previously set to default.

On page 2423, line 77606 (FUTURE DIRECTIONS) change:
None.
to:
A future version of this standard may define a mechanism to obtain the current setting of all traps (including those in their default state).

- Issue History
Date Modified Username Field Change
2018-09-28 02:22 kre New Issue
2018-09-28 02:22 kre Name => Robert Elz
2018-09-28 02:22 kre Section => XCU 2.14 -- trap special builtin
2018-09-28 02:22 kre Page Number => 2420
2018-09-28 02:22 kre Line Number => 77514 - 77526
2018-09-28 03:20 kre Tag Attached: tc3-2008
2018-09-28 03:20 kre Tag Attached: issue8
2018-09-28 03:20 kre Tag Detached: tc3-2008
2018-09-28 03:21 kre Tag Detached: issue8
2018-09-28 03:23 kre Note Added: 0004132
2018-09-28 08:44 geoffclare Note Added: 0004133
2018-09-28 08:53 geoffclare Note Added: 0004134
2018-09-28 09:04 geoffclare Note Edited: 0004133
2018-09-28 09:05 geoffclare Note Deleted: 0004134
2018-09-28 10:25 kre Note Added: 0004135
2018-09-28 10:40 kre Note Added: 0004136
2019-04-04 16:36 geoffclare Note Added: 0004355
2019-04-04 16:38 geoffclare Interp Status => ---
2019-04-04 16:38 geoffclare Final Accepted Text => Note: 0004355
2019-04-04 16:38 geoffclare Status New => Resolved
2019-04-04 16:38 geoffclare Resolution Open => Accepted As Marked
2019-04-04 16:38 geoffclare Tag Attached: tc3-2008
2019-04-09 11:19 geoffclare Relationship added related to 0001212
2019-11-12 15:40 geoffclare Status Resolved => Applied
2024-06-11 09:08 agadmin Status Applied => Closed

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