Minutes of the 26 March 2009 Teleconference Austin-450 Page 1 of 1 Submitted by Andrew Josey, The Open Group. March 27 , 2009 Attendees Andrew Josey, The Open Group Don Cragun, PASC OR Nick Stoughton, USENIX, ISO/IEC OR Geoff Clare, The Open Group David Korn, AT&T Mark Brown, IBM, TOG OR (partial) Apologies Ulrich Drepper, Red Hat * Bugzilla We did not discuss this at the call this week. We mentioned this briefly agreeing that from a workflow perspective we still had to finalize the handling of interpretations. * Aardvark review We picked up again on the latest rdvk reports. http://www.opengroup.org/austin/aardvark/latest/ XCUbug3 ERN 8 set -e Accept as marked below As per the circulated action, with a single change to removing the following paragraph When a function is executed, the effect of -e on the commands within the function body shall be as if the function body had appeared in place of the function name. XCUbug3 ERN 7 sh exit status Accept as marked below 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." XCUbug3 ERN 9 trap in subshell Accept as marked below Go with option 1 as stated in the proposed action, which allows for both solutions. XBDbug3 ERN 4 LC_TIME t_fmt_ampm It was noted that if t_fmt_ampm is an empty string, then applications should not use the value of am_pm. This should go down the interpretations track The standard does not address this issue, concerns are being forwarded to the sponsor. Consider as a revision for a future edition, requiring that am_pm be empty if t_fmt_ampm is an emptry string This would also need to be noted in the APPLICATION USAGE of related utilities/functions. Next meeting ------------ The next call will be on April 9 at 16:00 UK time/08:00 Pacific to carry on with the aardvark. See the calendar for the list of dialup numbers. An IRC channel will be available for the meeting irc://irc.freestandards.org #austin ICAL: http://www.google.com/calendar/ical/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic XML: http://www.google.com/calendar/feeds/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic