The following issue has been SUBMITTED.
======================================================================
http://austingroupbugs.net/view.php?id=1211
======================================================================
Reported By: kre
Assigned To:
======================================================================
Project: 1003.1(2016)/Issue7+TC2
Issue ID: 1211
Category: Shell and Utilities
Type: Clarification Requested
Severity: Objection
Priority: normal
Status: New
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:
======================================================================
Date Submitted: 2018-09-28 02:22 UTC
Last Modified: 2018-09-28 02:22 UTC
======================================================================
Summary: "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.)
======================================================================
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
======================================================================
