[1003.1(2016)/Issue7+TC2 0001211]: "trap" (with no args) specification does not match reality
A NOTE has been added to this issue. == 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 08:44 UTC == Summary:"trap" (with no args) specification does not match reality == -- (0004133) geoffclare (manager) - 2018-09-28 08:44 http://austingroupbugs.net/view.php?id=1211#c4133 -- The reason your test script produces no output is because you haven't set any traps! $ ksh -c 'trap foo INT; x=$(trap); echo "$x"' trap -- foo INT $ bash -c 'trap foo INT; x=$(trap); echo "$x"' trap -- 'foo' INT This issue was investigated in depth in 2009 via http://austingroupbugs.net/view.php?id=53 Do I have your permission to close this new bug as withdrawn? Issue History Date ModifiedUsername FieldChange == 2018-09-28 02:22 kreNew Issue 2018-09-28 02:22 kreName => Robert Elz 2018-09-28 02:22 kreSection => XCU 2.14 -- trap special builtin 2018-09-28 02:22 krePage Number => 2420 2018-09-28 02:22 kreLine Number => 77514 - 77526 2018-09-28 03:20 kreTag Attached: tc3-2008 2018-09-28 03:20 kreTag Attached: issue8 2018-09-28 03:20 kreTag Detached: tc3-2008 2018-09-28 03:21 kreTag Detached: issue8 2018-09-28 03:23 kreNote Added: 0004132 2018-09-28 08:44 geoffclare Note Added: 0004133 ==
[1003.1(2016)/Issue7+TC2 0001211]: "trap" (with no args) specification does not match reality
A NOTE has been added to this issue. == 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 08:53 UTC == Summary:"trap" (with no args) specification does not match reality == -- (0004134) geoffclare (manager) - 2018-09-28 08:53 http://austingroupbugs.net/view.php?id=1211#c4134 -- Sorry I missed the bit where you said "Shells only list traps that have been altered from the default". Please ignore http://austingroupbugs.net/view.php?id=1211#c4133. Issue History Date ModifiedUsername FieldChange == 2018-09-28 02:22 kreNew Issue 2018-09-28 02:22 kreName => Robert Elz 2018-09-28 02:22 kreSection => XCU 2.14 -- trap special builtin 2018-09-28 02:22 krePage Number => 2420 2018-09-28 02:22 kreLine Number => 77514 - 77526 2018-09-28 03:20 kreTag Attached: tc3-2008 2018-09-28 03:20 kreTag Attached: issue8 2018-09-28 03:20 kreTag Detached: tc3-2008 2018-09-28 03:21 kreTag Detached: issue8 2018-09-28 03:23 kreNote Added: 0004132 2018-09-28 08:44 geoffclare Note Added: 0004133 2018-09-28 08:53 geoffclare Note Added: 0004134 ==
[1003.1(2016)/Issue7+TC2 0001211]: "trap" (with no args) specification does not match reality
A NOTE has been added to this issue. == 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 10:25 UTC == Summary:"trap" (with no args) specification does not match reality == -- (0004135) kre (reporter) - 2018-09-28 10:25 http://austingroupbugs.net/view.php?id=1211#c4135 -- 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. Issue History Date ModifiedUsername FieldChange == 2018-09-28 02:22 kreNew Issue 2018-09-28 02:22 kreName => Robert Elz 2018-09-28 02:22 kreSection => XCU 2.14 -- trap special builtin 2018-09-28 02:22 krePage Number => 2420 2018-09-28 02:22 kreLine Number => 77514 - 77526 2018-09-28 03:20 kreTag Attached: tc3-2008 2018-09-28 03:20 kreTag Attached: issue8 2018-09-28 03:20 kreTag Detached: tc3-2008 2018-09-28 03:21 kreTag Detached: issue8 2018-09-28 03:23 kreNote 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 kreNote Added: 0004135 ==
[1003.1(2016)/Issue7+TC2 0001211]: "trap" (with no args) specification does not match reality
A NOTE has been added to this issue. == 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 10:40 UTC == Summary:"trap" (with no args) specification does not match reality == -- (0004136) kre (reporter) - 2018-09-28 10:40 http://austingroupbugs.net/view.php?id=1211#c4136 -- 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. Issue History Date ModifiedUsername FieldChange == 2018-09-28 02:22 kreNew Issue 2018-09-28 02:22 kreName => Robert Elz 2018-09-28 02:22 kreSection => XCU 2.14 -- trap special builtin 2018-09-28 02:22 krePage Number => 2420 2018-09-28 02:22 kreLine Number => 77514 - 77526 2018-09-28 03:20 kreTag Attached: tc3-2008 2018-09-28 03:20 kreTag Attached: issue8 2018-09-28 03:20 kreTag Detached: tc3-2008 2018-09-28 03:21 kreTag Detached: issue8 2018-09-28 03:23 kreNote 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 kreNote Added: 0004135 2018-09-28 10:40 kreNote Added: 0004136 ==
Several questions about $'...'
Hello, Recently I started implementing support for $'...' strings based on the proposed text in http://austingroupbugs.net/view.php?id=249 and later comments in my shell (dash-based personal hobby project), which has left me with a few questions. I understand that the text is not final and that any answers I receive now may be invalidated by future changes to the text. 1. Are the rules for determining the end of a dollar-quoted string intended to be fully specified, especially when taking into account strings that are never expanded? : || : $'\c' #1 : || : $'\c\'' #2 ? Unlike other shells, mksh takes the second ' in #1 as the operand to \c, and the backslash by itself in #2, so complains about a missing closing quote for both. Is any particular behaviour intended? 2. I am not able to fully understand the allowed unspecified effects of null byte handling. If a \xXX or \XXX escape sequence yields a byte whose value is 0, it is unspecified whether that nul byte is included in the result or if that byte and any following regular characters and escape sequences up to the terminating unescaped single-quote are evaluated and discarded. a. As mentioned in a comment already, \u can be used to produce a null byte as well, which is missing from the text, but is this also intended to apply to implementation-defined or unspecified forms of producing a null byte? Examples are \400, which produces a null byte on most implementations, but does not exhibit the same behaviour as \0 in mksh in how strings are terminated, and \c@. b. If the implementation includes that null byte in the result, how does it follow that printf a$'b\0c\''d is required by this standard to produce: abd while historic versions of ksh93 produced: ab If the null byte is included in the string, would not passing the complete string including null byte to the printf utility cause the output to be "ab"? 3. About the addition "during token recognition" for handling of \u and \U: when exactly does token recognition take place? Does this require, allow, or forbid implementations from parsing multiple commands prior to executing them, if one command may change the locale, but the $'...' string is part of a different later command? Does this require functions containing $'\u' to expand them according to the locale that was in effect when the function was defined, or are shells allowed to (re-)tokenise the function's commands when the function is executed or behave as if such re-tokenisation is taking place? 4. Does the implementation-defined aspect of handling of \u and \U "during token recognition" that are not part of the current locale's character set allow implementations to issue an error message at parse time? That is, assuming a shell decides to provide an error message for LC_ALL=C : $'\u1234' as zsh does, does this allow and/or require that same error message to be produced for LC_ALL=C : || : $'\u1234' Cheers, Harald van Dijk
