 Relationships |
|
| Anonymous | Login | Signup for a new account | 2010-02-09 14:46 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 | 2009-11-02 22:33 | |||||||
| Reporter | geoffclare | View Status | public | |||||||||
| Assigned To | ajosey | |||||||||||
| Priority | normal | Resolution | Accepted As Marked | |||||||||
| Status | Interpretation Required | |||||||||||
| Name | Geoff Clare | |||||||||||
| Organization | The Open Group | |||||||||||
| User Reference | ||||||||||||
| Section | sh | |||||||||||
| Page Number | 3175 | |||||||||||
| Line Number | 105726 | |||||||||||
| Interp Status | Approved | |||||||||||
| Final Accepted Text | Note: 0000090 | |||||||||||
| 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 | No tags attached. | |||||||||||
| 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." |
|
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 | |
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |  |
