Anonymous | Login | 2024-10-09 03:23 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0000051 | [1003.1(2008)/Issue 7] Shell and Utilities | Comment | Clarification Requested | 2009-06-25 13:04 | 2024-06-11 08:53 | ||
Reporter | geoffclare | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | ||||||
Name | Geoff Clare | ||||||
Organization | The Open Group | ||||||
User Reference | |||||||
Section | sh | ||||||
Page Number | 3175 | ||||||
Line Number | 105726 | ||||||
Interp Status | Approved | ||||||
Final Accepted Text | Note: 0005929 | ||||||
Summary | 0000051: sh exit status not clear for built-in terminated by a signal | ||||||
Description |
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. |
||||||
Desired 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." |
||||||
Tags | issue8 | ||||||
Attached Files | |||||||
|
Relationships | |||||||||||||||||||
|
Notes | |
(0000089) Don Cragun (manager) 2009-06-25 13:07 edited on: 2009-06-26 06:29 |
Originally reported by gwc:xxxxxxxxxxxxx Mon, 9 Mar 2009 09:36:34 +0000 with Subject: Defect in XCU sh Transcribed by Don Cragun from xcubug3.txt ERN 7 Submitter tag "gwc sh exit status" |
(0000090) Don Cragun (manager) 2009-06-25 13:11 edited on: 2009-10-09 16:01 |
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): ------------------------------------------------------- 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." |
(0004687) geoffclare (manager) 2019-12-18 15:02 edited on: 2020-01-20 15:03 |
Reopening because the instructions in the Notes to the Editor in Note: 0000090 regarding the getrlimit() and setrlimit() functions are unclear. Specifically, should all of the RLIMIT_* constants in <sys/resource.h> become mandatory, or only RLIMIT_CORE? The stated rationale for moving these functions to Base only requires RLIMIT_CORE to be mandated; the others could remain XSI. If the other constants are mandated, then this will have wide ranging effects elsewhere in the standard, e.g. SIGXCPU and SIGXFSZ in <signal.h>, and all text relating to the file size limit that is currently shaded XSI will need to have the shading removed. In addition, the changes to the exit builtin will need to be updated to incorporate changes from bugs 0001150 and/or 0001309. |
(0005929) geoffclare (manager) 2022-08-09 14:31 edited on: 2022-08-09 14:32 |
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>, remove 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: 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). Changes to XCU... On page 2315 line 74583 section 2.5.2, change: Expands to the shortest representation of the decimal exit status of the pipeline (see ...to: Expands to the shortest representation of the decimal exit status (see [xref to 2.8.2]) of the pipeline (see ... On page 2331 line 75257 section 2.8.2, change: 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.to: 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. On page 2369 line 76716 section 2.14 (exit DESCRIPTION), change: The exit utility shall cause the shell to exit from its current execution environment with the exit status specified by the unsigned decimal integer n. 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 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 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 n, if specified. On page 2369 line 76747 section 2.14 (exit EXIT STATUS), change: The exit status shall be n, if specified, except that the behavior is unspecified if n is not an unsigned decimal integer or is greater than 255. If n is not specified, the result shall be as if n were specified with the current value of the special parameter '?' (see [xref to 2.5.2]), except that when exit is executed in a trap action, the value for the special parameter '?' that is considered ``current'' shall be the value it had immediately preceding the trap action.to: The exit utility causes the shell to exit from its current execution environment, and therefore does not itself return an exit status. 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: See also [xref to XRAT C.2.8.2]. On page 3155 line 107015 section sh (EXIT STATUS), 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 [xref to 2.14]).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 [xref to 2.14]. Change to XRAT... On page 3640 line 125987 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.append: 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 ofexit $?orret=$? .... exit $retin 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. |
(0005932) agadmin (administrator) 2022-08-12 20:35 |
Interpretation Proposed: 12 August 2022 |
(0005970) agadmin (administrator) 2022-09-20 10:41 |
Interpretation Approved: 20 Sep 2022 |
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 => Note: 0000090 |
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 | |
2022-08-09 14:32 | geoffclare | Note Edited: 0005929 | |
2022-08-11 15:27 | Don Cragun | Final Accepted Text | Note: 0000090 => Note: 0005929 |
2022-08-11 15:27 | Don Cragun | Status | Under Review => Interpretation Required |
2022-08-11 15:27 | Don Cragun | Resolution | Reopened => Accepted As Marked |
2022-08-12 20:35 | agadmin | Interp Status | --- => Proposed |
2022-08-12 20:35 | agadmin | Note Added: 0005932 | |
2022-09-20 10:41 | agadmin | Interp Status | Proposed => Approved |
2022-09-20 10:41 | agadmin | Note Added: 0005970 | |
2022-10-21 08:56 | geoffclare | Status | Interpretation Required => Applied |
2023-04-17 14:22 | geoffclare | Relationship added | related to 0001669 |
2024-06-11 08:53 | agadmin | Status | Applied => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |