Last updated 26 June 2009 ______________________________________________________________________________ COMMENT Enhancement Request Number 1 khoroshilov:xxxxxxxxxxxxxxxx Bug in XCUd5.1 2.10.2 Shell Grammar (rdvk# 1) {LVC-S0679} Thu, 10 Jul 2008 22:02:30 +0100 (BST) ______________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Send down the interps track. The standard states the requirements for the shell grammar , and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. (Target for TC1) _______________________________________________________________________________ Page: 2329 Line: 73601-73602 Section: 2.10.2 Problem: The section 2.10.2 Shell Grammar Rules reads: else_part : Elif compound_list Then else_part | Else compound_list ; One can see that there should be Else or Elif right after Then. This is wrong. Action: We propose to modify this rule as follows: else_part : Elif compound_list Then compound_list | Elif compound_list Then compound_list else_part | Else compound_list ; ______________________________________________________________________________ COMMENT Enhancement Request Number 2 khoroshilov:xxxxxxxxxxxxxxxx Bug in XCUd5.1 2.9.3 Lists (rdvk# 2) {LVC-S0701} Fri, 1 Aug 2008 06:39:28 +0100 (BST) ______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Send down the interps track. The standard states the requirements for the shell grammar , and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. (Target for TC1) Change from: A list is a sequence of one or more AND-OR lists separated by the operators ; and & and optionally terminated by ;, &, or . To: A list is a sequence of one or more AND-OR lists separated by the operators ; and &. Change from "A ';' or terminator shall cause the preceding AND-OR list to be executed sequentially; an '&' shall cause asynchronous execution of the preceding AND-OR list." To: "A ';' separator or a ';' or terminator shall cause the preceding AND-OR list to be executed sequentially; an '&' separator or terminator shall cause asynchronous execution of the preceding AND-OR list." _______________________________________________________________________________ Page: 2319 Line: 73197-73198 Section:2.9.3 Problem: There is an inconsistency between formal definition of list in Shell Language Grammar and its informal description. The informal description of a list in section 2.9.3 Lists reads: 73197 A list is a sequence of one or more AND-OR lists separated by the operators ; and & and 73198 optionally terminated by ;, &, or . The formal definition of a list is as follows: 73528 list : list separator_op and_or 73529 | and_or 73530 ; ... 73668 separator_op : & 73669 | ; 73670 ; This definition corresponds to the first part of the description only: "A list is a sequence of one or more AND-OR lists separated by the operators ';' and '&'". Action: Fix the inconsistency. For example, replace A list is a sequence of one or more AND-OR lists separated by the operators ; and & and optionally terminated by ;, &, or . by A list is a sequence of one or more AND-OR lists separated by the operators ; and &. _____________________________________________________________________________ OBJECTION Enhancement Request Number 3 ebb9:xxxxxxx Defect in XCU date (rdvk# 1) {ebb.date} Fri, 9 Jan 2009 21:00:38 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is an enhancement, and should be added SD5 , items for consideration for the next revision. It should be noted that the proposed action does not address all the issues raised in the problem specifications. _____________________________________________________________________________ Page: 2575 Line: 82893 Section: date Problem: Edition of Specification (Year): 2008 Defect code : 2. Omission Although the date utility provides an interface similar to the strftime function, there are several things specified only for the latter (some with CX shading), which would be useful from a command line interface. These include: missing specifiers, addition of flags, addition of minimum field width. This aardvark only addresses missing specifiers. An alternative solution might be to couch the entire discussion of the format argument of the date utility in terms of a call to strftime, so that the next time the strftime interface is extended, the date utility implicitly picks up that extension; this would also pick up the '0' and '+' flags as well as minimum field width. Action: At line 82893, insert: %F Date in the format %Y-%m-%d %g The last 2 digits of the week-based year (see %V) as a decimal number [00,99]. %G The week-based year (see %V) as a decimal number (for example, 1977). At line 82903, insert: %R Time in the format %H:%M. At line 82922, insert: %z The offset from UTC in the ISO 8601:2000 standard format (+hhmm or -hhmm), or by no characters if no timezone is determinable. For example, "-0430" means 4 hours 30 minutes behind UTC (west of Greenwich). _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 gwc:xxxxxxxxxxxxx Defect in XCU mv (rdvk# 2) [gwc mv AI-016] Fri, 9 Jan 2009 15:42:20 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2955 Line: 97288 Section: mv Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The following text was added to the end of the first paragraph on the mv page in the 2008 revision, as a result of interpretation AI-016: "In this case, if target_file ends with a trailing character, mv shall treat this as an error and no source_file operands will be processed." Here, "in this case" is a reference to "the final operand does not name an existing directory and is not a symbolic link referring to an existing directory". This is fine for the case where an attempt is made to rename a non-directory file, e.g.: mv regular_file new_name/ but I can see no reason that an attempt to rename a directory should fail, e.g.: mv existing_dir new_dir/ or: mv existing_dir/ new_dir/ Indeed, these commands work on Solaris 10. Action: Change "In this case, if target_file ends with a trailing ..." to "In this case, if source_file names a non-directory file and target_file ends with a trailing ..." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 5 gwc:xxxxxxxxxxxxx Defect in XCU 2.6 (rdvk# 1) [gwc word expansions $] Thu, 19 Feb 2009 15:11:10 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2305 Line: 72669 Section: 2.6 Problem: Edition of Specification (Year): 2008 Defect code : 1. Error 2.6 Word Expansions says: If an unquoted '$' is followed by a character that is either not numeric, the name of one of the special parameters (see Section 2.5.2, on page 2302), a valid first character of a variable name, a ('{') or a , the result is unspecified. Obviously the intention is that the "not" should negate all of the listed types of characters, but that is not how the sentence reads to me. It could perhaps be fixed by changing "either not" to "not either", but the wording would still be somewhat awkward. The action proposed below is a more extensive rewording that hopefully is much clearer. Action: Change: If an unquoted '$' is followed by a character that is either not numeric, the name of one of the special parameters (see Section 2.5.2, on page 2302), a valid first character of a variable name, a ('{') or a , the result is unspecified. to: If an unquoted '$' is followed by a character that is not one of the following: * a numeric character * the name of one of the special parameters (see Section 2.5.2, on page 2302) * a valid first character of a variable name * a ('{') * a the result is unspecified. _____________________________________________________________________________ OBJECTION Enhancement Request Number 6 gwc:xxxxxxxxxxxxx Defect in XCU 2.6.4 (rdvk# 2) [gwc shell integer constants] Thu, 19 Feb 2009 15:17:22 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 2310 Line: 72861 Section: 2.6.4 Problem: Edition of Specification (Year): 2008 Defect code : 3. Clarification required XCU 2.6.4 states: If the shell variable x contains a value that forms a valid integer constant, then the arithmetic expansions "$((x))" and "$(($x))" shall return the same value. This seems fine at face value, but earlier in the same section is the following statement: Only the decimal-constant, octal-constant, and hexadecimal-constant constants specified in the ISO C standard, Section 6.4.4.1 are required to be recognized as constants. This statement is specifically about arithmetic expressions, but could be taken to affect the requirements about shell variable contents as well. In which case, shell variables containing negative values are not required to be supported. When clarifying this for minus signs, it is probably worth including plus signs as well. All the shells I have tried accept: x='+2'; echo $((x)) This is also consistent with the printf utility, which is required to accept constants "as described by the ISO C standard, with the following extensions: * A leading plus or minus sign shall be allowed". In addition, in the later statement: If the expression is invalid, the expansion fails and the shell shall write a message to standard error indicating the failure. it is not clear whether this only applies to the expression itself, or also to the contents of shell variables used in the expression. Since shells can, as an extension, support the use of variables with non-constant contents, the change here needs to be carefully worded so as not to imply that anything that is not a valid constant produces an error. Action: Change "If the shell variable x contains a value that forms a valid integer constant, then" to "If the shell variable x contains a value that forms a valid integer constant, optionally including a leading plus or minus sign, then" At line 72866, change "If the expression is invalid, the expansion fails and the shell shall write a message to standard error indicating the failure." to "If the expression is invalid, or the contents of a shell variable used in the expression are not recognized by the shell, the expansion fails and the shell shall write a diagnostic message to standard error indicating the failure." _____________________________________________________________________________ COMMENT Enhancement Request Number 7 gwc:xxxxxxxxxxxxx Defect in XCU sh (rdvk# 1) [gwc sh exit status] Mon, 9 Mar 2009 09:36:34 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: We agreed to accept Geoff's proposal (austin-mar2008 seq 79) enclosed. Send down the interpretations track. The standard is clear, concerns are being forwarded to the sponsor. Instructions to the editors for a future revision of the specification. The setrlimit and getrlimit functions in XSH should move from XSI to Base Note as the rationale for the move: These are being moved to the Base so that portable shells can be written that can catch a signal that caused a subshell to exit while dropping a core file, to relay the status without overwriting the core file. Changes to XCU: In the EXIT STATUS section for the sh utility (P&L in the aarvark header) change "Otherwise, the shell shall return the exit status of the last command it invoked or attempted to invoke (see also the exit utility in Section 2.14, on page 2334)." to "Otherwise, the shell shall terminate in the same manner as for an exit command with no operands, unless the last command the shell invoked was executed without forking, in which case the wait status seen by the parent process of the shell shall be the wait status of the last command the shell invoked. See the exit utility in Section 2.14, on page 2334." In the DESCRIPTION section for the exit builtin utility at page 2347 line 74214 section 2.14, change "The exit utility shall cause the shell to exit with the exit status specified by the unsigned decimal integer n. If n is specified, but its value is not between 0 and 255 inclusively, the exit status is undefined." to "The exit utility shall cause the shell to terminate. The wait status of the shell shall be determined by the unsigned decimal integer n, if specified. If n is specified and has a value between 0 and 255 inclusive, the wait status of the shell shall indicate that it exited with exit status n. If n is specified and has a value greater than 256 that corresponds to an exit status the shell assigns to commands terminated by a valid signal (see [xref to 2.8.2]), the wait status of the shell shall indicate that it was terminated by that signal. No other actions associated with the signal, such as execution of traps or creation of a core file, shall be performed by the shell. If n is specified and has a value of 256, or greater than 256 but not corresponding to an exit status the shell assigns to commands terminated by a valid signal, the wait status of the shell is unspecified. If n is not specified, the wait status of the shell shall be determined as follows: * If the exit status the shell assigned to the last command it invoked or attempted to invoke was less than 256, the wait status of the shell shall indicate that it exited with the same exit status. * If the exit status the shell assigned to the last command it invoked was greater than 256, the wait status of the shell shall indicate that it was terminated by the same signal that terminated the last command. No other actions associated with the signal, such as execution of traps or creation of a core file, shall be performed by the shell. * If the shell did not invoke or attempt to invoke any commands before executing the exit utility, the wait status of the shell shall indicate that it exited with exit status zero." In the EXIT STATUS section for the exit builtin utility at page 2347 line 74240 section 2.14, change "The exit status shall be n, if specified. Otherwise, the value shall be the exit value of the last command executed, or zero if no command was executed." to "Since the exit utility causes the shell to terminate, it does not return an exit status to the shell. See the DESCRIPTION for details of the wait status of the shell." In the APPLICATION USAGE section for the exit builtin utility at page 2348 line 74247 section 2.14, replace "None" with the text from the RATIONALE section at line 74254. In the RATIONALE section for the exit builtin utility at page 2348 line 74254 section 2.14, replace the current text with "See [xref to XRAT C.2.8.2]." At page 2316 line 73066 section 2.8.2, change "When reporting the exit status with the special parameter '?', the shell shall report the full eight bits of exit status available. The exit status of a command that terminated because it received a signal shall be reported as greater than 128." to "When a command is terminated by a signal, the shell shall assign it an exit status greater than 128. The exit status shall identify, in an implementation-defined manner, which signal terminated the command. When a command terminates normally, the exit status reported with the special parameter '?' shall represent the full eight bits of exit status." At page 2302 line 72527 section 2.5.2, change "Expands to the decimal exit status of the most recent pipeline (see Section 2.9.2, on page 2318)." to "Expands to the decimal exit status (see [xref to 2.8.2]) of the most recent pipeline (see Section 2.9.2, on page 2318)." Cross-volume change to XRAT: At page 3662 line 124582 section C.2.8.2, after "Implementations are encouraged to choose exit values greater than 256 to indicate programs that terminate by a signal so that the exit status cannot be confused with an exit status generated by a normal termination." add "However, the use of exit values greater than 256 poses a problem for the shell's own exit status. Historically this was the exit status of the last command invoked by the shell, but if the last command was terminated by a signal and was assigned an exit status greater than 256 by the shell, this value would be truncated to eight bits in the shell's exit status. Likewise truncation would occur with use of exit $? or ret=$? .... exit $ret in shell scripts. To avoid this truncation, shells which assign exit statuses greater than 256 are required to propagate the wait status of the last command to the shell's own wait status (by sending itself the same signal), and to handle exit values greater than 256 passed to the exit builtin by mimicking the wait status that would give rise to assignment of that exit status in the shell. Note that this requirement does not apply to signals that do not cause termination, such as SIGCHLD, since the shell can never actually assign a corresponding exit status greater than 256, and the requirement is worded in terms of this assignment." _____________________________________________________________________________ Page: 3175 Line: 105726 Section: sh Problem: Edition of Specification (Year): 2008 Defect code : 3. Clarification required The EXIT STATUS section for the sh utility says: The following exit values shall be returned: [...] Otherwise, the shell shall return the exit status of the last command it invoked or attempted to invoke and the EXIT STATUS section for the exit built-in utility says: The exit status shall be n, if specified. Otherwise, the value shall be the exit value of the last command executed, or zero if no command was executed. It is not clear how these statements are supposed to be interpreted in the case where the last command the shell invoked was terminated by a signal. Section 2.8.2 talks about exit status on termination by a signal, but from the context it appears only to apply to the value of the $? special parameter: When reporting the exit status with the special parameter '?', the shell shall report the full eight bits of exit status available. The exit status of a command that terminated because it received a signal shall be reported as greater than 128. I think the intention is that when the last command is terminated by a signal, the shell's exit status should be the same value that would have been reported in $? after the command. That is how all of the shells I have tested behave, with two exceptions: 1. Some shells have an optimisation where, in some circumstances, they execute the last command without forking (i.e. as if the script had ended with "exec last_command"). When this is done, the parent of the shell will see a wait status that looks as if the shell itself was terminated by the signal: $ echo 'kill $$' > killself; chmod +x killself $ ksh -c './killself' & [1] 6535 [1] + Terminated ksh -c './killself' & $ If the shell needs to make use of the command's exit status, the optimisation is not used: $ ksh -c './killself && true' & [1] 6538 $ ksh: 6539 Terminated [1] + Done(143) ksh -c './killself && true' & $ While the behaviour with this optimisation may be a little misleading to the parent of the shell, the optimisation is a worthwhile feature, and on balance I think the standard should be modified to allow it. 2. In ksh93 when a command is terminated by a signal, it assigns an exit status of 256 plus the signal number. When the shell then tries to use this as its own exit status, it gets truncated to 8 bits (thus the exit status of the shell is the signal number): $ ksh93 -c './killself; exit' & [1] 22214 $ ksh93: line 1: 22216: Terminated [1] + Done(15) ksh93 -c './killself; exit' & $ $ ksh93 -c './killself && true' & [1] 22218 $ [1] + Done(15) ksh93 -c './killself && true' & $ I consider the exit status of 256+signum in ksh93, instead of 128+signum as in other shells, to be an undesirable misfeature. As well as making the shell's exit status non-conforming as discussed here, it also breaks "wrapper" scripts that execute other commands after the one being wrapped: wrapped_command "$@" ret=$? other_command exit $ret If wrapped_command is terminated by a signal, with ksh93 the exit status of the wrapper script will be the signal number. With other shells it will be 128+signum, which means that if the wrapper script was executed from a shell, the value of $? in that shell is the same as if wrapped_command had been executed directly. For these reasons, the proposed action below does not modify the requirements on shell exit status to allow this second exception. Instead it enforces the normal relationship between the shell's exit status and the exit status of the last command by requiring that when a command is terminated by a signal its exit status is greater than 128 and less than 256, thus ensuring that truncation does not occur. It also modifies XRAT C.2.8.2 which, unfortunately, encourages this misfeature. Finally, the EXIT STATUS section for sh has some text about the shell attempting to invoke the last command, which is missing from the EXIT STATUS section for the exit builtin, and the text in the RATIONALE section for the exit builtin should be in APPLICATION USAGE. Action: Change "Otherwise, the shell shall return the exit status of the last command it invoked or attempted to invoke (see also the exit utility in Section 2.14, on page 2334)." to "Otherwise, the shell shall return the exit status of the last command it invoked or attempted to invoke (see [xref to 2.8.2]), unless the shell invoked the last command without forking, in which case the wait status seen by the parent process of the shell shall be the wait status of the last command the shell invoked. See also the exit utility in Section 2.14, on page 2334." In the EXIT STATUS section for the exit builtin utility at page 2347 line 74240 section 2.14, change "The exit status shall be n, if specified. Otherwise, the value shall be the exit value of the last command executed, or zero if no command was executed." to "The exit status of the shell shall be n, if specified. Otherwise, the exit status of the shell shall be the exit status of the last command the shell invoked or attempted to invoke (see [xref to 2.8.2]), or zero if the shell did not invoke or attempt to invoke any commands before executing the exit utility." In the APPLICATION USAGE section for the exit builtin utility at page 2348 line 74247 section 2.14, replace "None" with the text from the RATIONALE section at line 74254. In the RATIONALE section for the exit builtin utility at page 2348 line 74254 section 2.14, replace the current text with "None". At page 2316 line 73066 section 2.8.2, change "When reporting the exit status with the special parameter '?', the shell shall report the full eight bits of exit status available. The exit status of a command that terminated because it received a signal shall be reported as greater than 128." to "When a command is terminated by a signal, the shell shall assign it an exit status greater than 128 and less than 256. When reporting the exit status with the special parameter '?', the shell shall report the full eight bits of exit status." At page 2302 line 72527 section 2.5.2, change "Expands to the decimal exit status of the most recent pipeline (see Section 2.9.2, on page 2318)." to "Expands to the decimal exit status (see [xref to 2.8.2]) of the most recent pipeline (see Section 2.9.2, on page 2318)." Cross-volume change to XRAT: At page 3662 line 124576 section C.2.8.2, change "Historically, shells have returned an exit status of 128+n, where n represents the signal number. Since signal numbers are not standardized, there is no portable way to determine which signal caused the termination. Also, it is possible for a command to exit with a status in the same range of numbers that the shell would use to report that the command was terminated by a signal. Implementations are encouraged to choose exit values greater than 256 to indicate programs that terminate by a signal so that the exit status cannot be confused with an exit status generated by a normal termination." to "Historically, shells have returned an exit status of 128+n, where n represents the signal number. Since signal numbers are not standardized, there is no portable way to determine which signal caused the termination, and therefore the standard just requires that the exit status is greater than 128 and less than 256. It is possible for a command to exit with a status in the same range of numbers that the shell would use to report that the command was terminated by a signal. Earlier versions of this rationale suggested that implementations could avoid this problem by choosing exit values greater than 256 to indicate termination by a signal; however, shells which do this do not conform to the requirements of the EXIT STATUS section for the sh utility if the last command the shell invoked was terminated by a signal. The requirement to use exit values less than 256 does not affect portable applications as they already need to ensure they do not choose exit values greater than 128 for other purposes, since all versions of this standard have allowed the shell to use values greater than 128 to indicate termination by a signal." _____________________________________________________________________________ OBJECTION Enhancement Request Number 8 gwc:xxxxxxxxxxxxx Defect in XCU 2.14 set (rdvk# 2) [gwc set -e] Wed, 18 Mar 2009 09:24:16 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (The aardvark has been fixed up with the final action) _____________________________________________________________________________ Page: 2358 Line: 74545 Section: 2.14 Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The description of set -e does not match existing practice in several respects, as discussed at length on the austin-group-l mailing list in threads beginning 2009-02-10 ("error handling in shell pipelines") and 2009-02-17 ("set -e description"). The new description of set -e proposed below is taken from the minutes of the March 12th teleconference, with a few minor changes: * shallification * changed "!" to "the ! reserved word" * changed "2.8.1" to "[xref to 2.8.1]" * changed "AND or OR list" to "AND-OR list" and the two major changes, related to pipelines and functions, discussed in replies to the minutes. I have also added the fix to 2.9.2 identified during the original discussion, and some application usage and rationale. Action: Replace the description of -e with: -e When this option is on, when any command fails (for any of the reasons listed in [xref to 2.8.1] or by returning an exit status greater than zero) the shell immediately shall exit with the following exceptions: 1) The failure of any individual command in a multi-command pipeline shall not cause the shell to exit. Only the failure of the pipeline itself shall be considered. 2) The -e setting shall be ignored when executing the compound list following the while, until, if, or elif reserved word, a pipeline beginning with the ! reserved word, or any command of an AND-OR list other than the last. 3) If the exit status of a compound command other than a subshell command was the result of a failure while -e was being ignored, then -e shall not apply to this command. This requirement applies to the shell environment and each subshell environment separately. For example, in set -e; (false; echo one) | cat; echo two the false command causes the subshell to exit without executing echo one; however, echo two is executed because the exit status of the pipeline (false; echo one) | cat is zero. In the APPLICATION USAGE for the set builtin utility at page 2360 line 74631, change "None" to: Application writers should avoid relying on set -e within functions. For example, in the following script: set -e start() { some_server echo some_server started successfully } start || echo >&2 some_server failed the -e setting is ignored within the function body (because the function is a command in an AND-OR list other than the last). Therefore if some_server fails, the function carries on to echo "server started successfully", and the exit status of the function is zero (which means "server failed" is not output). In the RATIONALE for the set builtin utility after page 2361 line 74660, add a new paragraph: The description of the -e option is intended to match the behavior of the 1988 version of the KornShell. At page 2319 line 73188 section 2.9.2, change: If the reserved word ! does not precede the pipeline, the to: If the pipeline does not begin with the ! reserved word, the _____________________________________________________________________________ OBJECTION Enhancement Request Number 9 gwc:xxxxxxxxxxxxx Defect in XCU 2.14 trap (rdvk# 1) [gwc trap in subshell] Thu, 19 Mar 2009 11:15:35 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Go with option 1 below _____________________________________________________________________________ Page: 2368 Line: 74879 Section: 2.14 Problem: Edition of Specification (Year): 2008 Defect code : 1. Error 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.) 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." _____________________________________________________________________________ OBJECTION Enhancement Request Number 10 hanpingtian:xxxxxxxxx Defect in XCU 2.10.2 Shell Grammar Rules (rdvk# 1) {N/A} Wed, 20 May 2009 07:20:14 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_1_ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 0 Line: 0 Section: 2.10.2 Problem: Edition of Specification (Year): 2008 Defect code : 1. Error This is wrong: else_part : Elif compound_list Then else_part | Else compound_list It should be else_part : Elif compound_list Then compound_list else_part | Else compound_list Action: Change this: else_part : Elif compound_list Then else_part | Else compound_list to this one: else_part : Elif compound_list Then compound_list else_part | Else compound_list _____________________________________________________________________________ OBJECTION Enhancement Request Number 11 dcragun:xxxxxxxxx Defect in XCU cal (rdvk# 1) {dwc-cal} Tue, 9 Jun 2009 01:29:01 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Send down the interps track _____________________________________________________________________________ Page: 2499 Line: 79981, Section: cal Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The description of the operands is confusing and incorrect in the case when only one operand is given on the cal command line. If one operand (year) is given, the output should be a 12 month calendar for the given year. But, the current description says that the output shold be a one month calendar for the current date's month in the specified year. If no operands are given on the cal command line, the output should be a calendar for the current month in the current year. This is as specified in the operands section. If both operands are given, the output should be a one month calendar for the given month in the given year. Since there are no defaults in this case, this is correct as well. Action: Since we are requesting a change to the description of the way implementations are required to act, this aardvark request should be sent down the interpresentations track (with code phrases Standard is clear, Standard is wrong, concerns have been forwarded to the sponsor). Suggested wording for the next technical corrigenda or revision: Add a new paragraph to the DESCRIPTION of cal after P2499, L79975: If no operands are given, cal shall produce a one month calendar for the current month in the current year. If only the year operand is given, cal shall produce a calendar for all twelve months in the given calendar year. If both month and year operands are given, cal shall produce a one month calendar for the given month in the given year. Delete: The default shall be the current month. from P2499, L79981. Delete: The default shall be the current year. from P2499, L79983. Change: None. in the RATIONALE on P2500, L80028 to: Earlier versions of this standard incorrectly required that the command: cal 2000 write a one month calendar for the current calendar month (no matter what the current year is) in the year 2000 to standard output. This did not match historic practice in any known version of the cal utility. The description has been updated to match historic practice. When only the year operand is given, cal writes a twelve month calendar for the specified year. --last bug = 11