A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=51 ====================================================================== Reported By: geoffclare Assigned To: ajosey ====================================================================== Project: 1003.1(2008)/Issue 7 Issue ID: 51 Category: Shell and Utilities Type: Clarification Requested Severity: Comment Priority: normal Status: Under Review Name: Geoff Clare Organization: The Open Group User Reference: Section: sh Page Number: 3175 Line Number: 105726 Interp Status: --- Final Accepted Text: https://austingroupbugs.net/view.php?id=51#c90 ====================================================================== Date Submitted: 2009-06-25 13:04 UTC Last Modified: 2022-08-09 14:31 UTC ====================================================================== Summary: sh exit status not clear for built-in terminated by a signal ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001150 exit status of command substitution not... related to 0001309 Clarity needed for initial value of $? ... ======================================================================
---------------------------------------------------------------------- (0005929) geoffclare (manager) - 2022-08-09 14:31 https://austingroupbugs.net/view.php?id=51#c5929 ---------------------------------------------------------------------- Suggested new resolution... This retains XSI shading on the RLIMIT_* constants that are related to other XSI features. Interpretation response ------------------------ The standard states the requirements for sh exit status, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ------------- None. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Page and line numbers are for Issue 8 draft 2.1. Changes to XBD... On page 372 line 12870 section <sys/resource.h>, removing XSI shading from the SYNOPSIS. On page 372 line 12872-12876 section <sys/resource.h>, add XSH shading to the PRIO_* constants and their introductory text. On page 372 line 12887-12890 section <sys/resource.h>, add XSH shading to the RUSAGE_* constants and their introductory text. On page 372 line 12895-12898 section <sys/resource.h>, add XSH shading to the text describing the rusage structure. On page 372 line 12899 section <sys/resource.h>, add XSH shading to the text requiring the timeval structure to be defined. On page 372 line 12903 section <sys/resource.h>, and page 373 line 12905 section <sys/resource.h>, add XSI shading to RLIMIT_CPU and RLIMIT_FSIZE. On page 372 line 12911, 12913, 12914 section <sys/resource.h>, add XSH shading to the declarations of getpriority(), getrusage(), and setpriority(). On page 372 line 12916 section <sys/resource.h>, add XSH shading to the text requiring id_t to be defined. Changes to XSH... On page 1074 line 36699-36701 section getrlimit(), remove XSI shading from the SYNOPSIS. On page 1074 line 36724-36727 section getrlimit(), add XSI shading to RLIMIT_CPU. On page 1074 line 36731-36736 section getrlimit(), add XSI shading to RLIMIT_FSIZE. On page 1076 line 36789 section getrlimit(), add a new 1st paragraph to RATIONALE:<blockquote>These functions were previously part of the XSI option and have been moved to the Base so that portable shells, and other utilities that need to relay the wait status of a child process to a parent, can terminate themselves with the same signal that terminated the child but without overwriting a core image created by the child (through setting RLIMIT_CORE to zero, which disables core image creation). The RLIMIT_CPU and RLIMIT_FSIZE limits remain in the XSI option because they relate to other XSI functionality (SIGXCPU and SIGXFSZ).</blockquote> Changes to XCU... On page 2315 line 74583 section 2.5.2, change:<blockquote>Expands to the shortest representation of the decimal exit status of the pipeline (see ...</blockquote>to:<blockquote>Expands to the shortest representation of the decimal exit status (see [xref to 2.8.2]) of the pipeline (see ...</blockquote> On page 2331 line 75257 section 2.8.2, change:<blockquote>Otherwise, if the command terminated due to the receipt of a signal that was not caught, the exit status shall be greater than 128. Note that shell implementations are permitted to use an exit status greater than 255 if a command terminates due to a signal.</blockquote>to:<blockquote>Otherwise, if the command terminated due to the receipt of 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. Note that shell implementations are permitted to assign an exit status greater than 255 if a command terminates due to a signal.</blockquote> On page 2369 line 76716 section 2.14 (exit DESCRIPTION), change:<blockquote>The <i>exit</i> utility shall cause the shell to exit from its current execution environment with the exit status specified by the unsigned decimal integer <i>n</i>. If the current execution environment is a subshell environment, the shell shall exit from the subshell environment with the specified exit status and continue in the environment from which that subshell environment was invoked; otherwise, the shell utility shall terminate with the specified exit status. If <i>n</i> is specified, but its value is not between 0 and 255 inclusively, the exit status is undefined.</blockquote>to:<blockquote>The <i>exit</i> utility shall cause the shell to exit from its current execution environment. If the current execution environment is a subshell environment, the shell shall exit from the subshell environment and continue in the environment from which that subshell environment was invoked; otherwise, the shell utility shall terminate. The wait status of the shell or subshell shall be determined by the unsigned decimal integer <i>n</i>, if specified. If <i>n</i> is specified and has a value between 0 and 255 inclusive, the wait status of the shell or subshell shall indicate that it exited with exit status <i>n</i>. If <i>n</i> 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 Exit Status for Commands]), the wait status of the shell or subshell shall indicate that it was terminated by that signal. No other actions associated with the signal, such as execution of <i>trap</i> actions or creation of a core image, shall be performed by the shell. If <i>n</i> is specified and is not an unsigned decimal integer, or has a value of 256, or has a value 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 or subshell is unspecified. If <i>n</i> is not specified, the result shall be as if <i>n</i> were specified with the current value of the special parameter '?' (see [xref to 2.5.2]), except that when <i>exit</i> is executed in a <i>trap</i> action, the value for the special parameter '?' that is considered ``current'' shall be the value it had immediately preceding the <i>trap</i> action.</blockquote> On page 2369 line 76747 section 2.14 (exit EXIT STATUS), change:<blockquote>The exit status shall be <i>n</i>, if specified, except that the behavior is unspecified if <i>n</i> is not an unsigned decimal integer or is greater than 255. If <i>n</i> is not specified, the result shall be as if <i>n</i> were specified with the current value of the special parameter '?' (see [xref to 2.5.2]), except that when <i>exit</i> is executed in a <i>trap</i> action, the value for the special parameter '?' that is considered ``current'' shall be the value it had immediately preceding the <i>trap</i> action.</blockquote>to:<blockquote>The <i>exit</i> utility causes the shell to exit from its current execution environment, and therefore does not itself return an exit status.</blockquote> On page 2370 line 76755 section 2.14 (exit APPLICATION USAGE), replace "None" with the text from the RATIONALE section at lines 76769-76773. On page 2370 line 76779 section 2.14 (exit RATIONALE), add a new paragraph:<blockquote>See also [xref to XRAT C.2.8.2].</blockquote> On page 3155 line 107015 section sh (EXIT STATUS), change:<blockquote>Otherwise, the shell shall return the exit status of the last command it invoked or attempted to invoke (see also the <i>exit</i> utility in [xref to 2.14]).</blockquote>to:<blockquote>Otherwise, the shell shall terminate in the same manner as for an <i>exit</i> 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 <i>exit</i> utility in [xref to 2.14].</blockquote> Change to XRAT... On page 3640 line 125987 section C.2.8.2, after:<blockquote>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.</blockquote>append:<blockquote>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<pre>exit $?</pre> or<pre>ret=$? .... exit $ret</pre> 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.</blockquote> Issue History Date Modified Username Field Change ====================================================================== 2009-06-25 13:04 Don Cragun New Issue 2009-06-25 13:04 Don Cragun Status New => Under Review 2009-06-25 13:04 Don Cragun Assigned To => ajosey 2009-06-25 13:04 Don Cragun Name => Geoff Clare 2009-06-25 13:04 Don Cragun Organization => The Open Group 2009-06-25 13:04 Don Cragun Section => sh 2009-06-25 13:04 Don Cragun Page Number => 3175 2009-06-25 13:04 Don Cragun Line Number => 105726 2009-06-25 13:07 Don Cragun Note Added: 0000089 2009-06-25 13:11 Don Cragun Note Added: 0000090 2009-06-25 13:11 Don Cragun Reporter Don Cragun => geoffclare 2009-06-25 13:11 Don Cragun Status Under Review => Interpretation Required 2009-06-25 13:11 Don Cragun Resolution Open => Accepted As Marked 2009-06-25 16:38 Don Cragun Tag Attached: real bug in aardvark 2009-06-26 06:29 Don Cragun Note Edited: 0000089 2009-06-26 08:49 Don Cragun Final Accepted Text => Note 0000090 2009-06-26 09:31 Don Cragun Final Accepted Text Note 0000090 => https://austingroupbugs.net/view.php?id=51#c90 2009-07-30 16:09 Don Cragun Tag Detached: real bug in aardvark 2009-08-11 16:22 Don Cragun Interp Status => Pending 2009-09-17 15:41 nick Interp Status Pending => Proposed 2009-10-09 16:01 ajosey Note Edited: 0000090 2009-10-09 16:01 ajosey Interp Status Proposed => Approved 2009-11-02 22:33 user83 Note Added: 0000275 2009-11-02 22:33 user83 Note Added: 0000276 2009-11-02 23:10 user83 Note Deleted: 0000275 2009-11-02 23:10 user83 Note Deleted: 0000276 2010-09-20 09:03 geoffclare Tag Attached: issue8 2019-12-18 15:02 geoffclare Interp Status Approved => --- 2019-12-18 15:02 geoffclare Note Added: 0004687 2019-12-18 15:02 geoffclare Status Interpretation Required => Under Review 2019-12-18 15:02 geoffclare Resolution Accepted As Marked => Reopened 2020-01-20 15:03 geoffclare Note Edited: 0004687 2020-01-20 15:03 geoffclare Relationship added related to 0001150 2020-01-20 15:04 geoffclare Relationship added related to 0001309 2022-08-09 14:31 geoffclare Note Added: 0005929 ======================================================================
