Anonymous | Login | 2024-05-04 13:08 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 | ||
0000717 | [1003.1(2013)/Issue7+TC1] Shell and Utilities | Objection | Clarification Requested | 2013-06-28 09:45 | 2019-06-10 08:55 | ||
Reporter | geoffclare | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | ||||||
Name | Geoff Clare | ||||||
Organization | The Open Group | ||||||
User Reference | |||||||
Section | 2.14 exit | ||||||
Page Number | 2370 | ||||||
Line Number | 75508 | ||||||
Interp Status | Approved | ||||||
Final Accepted Text | See Note: 0001683. | ||||||
Summary | 0000717: meaning of "the shell shall exit" in a subshell environment | ||||||
Description |
The description of the exit special built-in says that it "shall cause the shell to exit", but it is not clear what this means when exit is executed in a subshell environment. The intention, and existing practice, is that the shell exits from the subshell environment only, not the entire shell. For example: echo one $(exit; echo two); echo three outputs one and three. This is consistent with the behaviour for errors encountered by special built-ins as described in section 2.8.1 Consequences of Shell Errors (although this has some wording problems): If any of the errors shown as "shall exit" or "(may) exit" occur in a subshell, the subshell shall (respectively may) exit with a non-zero status, but the script containing the subshell shall not exit because of the error. There are similar problems with the use of "shall exit" in the descriptions of the set -e and -u options. For example: set -e; echo one $(false; echo two); echo three set -u; echo one $(echo $unsetvar; echo two); echo three also both output one and three (plus an error message in the -u case). These can be fixed by adding an "as if" referring to exit. |
||||||
Desired Action |
Change: The exit utility shall cause the shell to exit with the exit status specified by the unsigned decimal integer n. to: 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. After page 2371 line 75546 section 2.14 exit add to EXAMPLES: Propagate error handling from within a subshell: ( command1 || exit 1 command2 || exit 1 exec command3 ) > outputfile || exit 1 echo "outputfile created successfully" At page 2337 line 74300 section 2.8.1 change If any of the errors shown as "shall exit" or "(may) exit" occur in a subshell, the subshell shall (respectively may) exit with a non-zero status, but the script containing the subshell shall not exit because of the error. to If any of the errors shown as "shall exit" or "(may) exit" occur in a subshell environment, the shell shall (respectively may) exit from the subshell environment with a non-zero status and continue in the environment from which that subshell environment was invoked. At page 2381 line 75846 section 2.14 set change: the shell immediately shall exit with the following exceptions to: the shell immediately shall exit, as if by executing the exit special built-in utility with no arguments, with the following exceptions At page 2382 line 75907 section 2.14 set change: exit status of the shell the command shall be treated as having been executed and returned an exit status of between 1 and 125 inclusive. A non-interactive shell shall immediately exit. to: exit status of the shell or subshell the command shall be treated as having been executed and returned an exit status of between 1 and 125 inclusive. A non-interactive shell shall immediately exit, as if by executing the exit special built-in utility with no arguments. |
||||||
Tags | tc2-2008 | ||||||
Attached Files | |||||||
|
Relationships | ||||||
|
Notes | |
(0001660) jilles (reporter) 2013-06-30 21:06 |
The part about 'set -u' does not match what the Bourne shell and ksh93 do. In most shells, a 'set -u' failure is treated like an expansion error, very similar to the one generated by the ${parameter?} expansion. Furthermore, the Bourne shell and ksh93 treat an expansion error in a redirection or assignment as a redirection or assignment error, respectively. For example, ksh93 -uc 'true <$x; echo continued $?' ksh93 -uc 'v=$x true; echo continued $?' ksh93 -uc '<$x; echo continued $?' all print "continued 1" after the error message. I think this is less useful than exiting (for 'set -u' as well as ${parameter?}, arithmetic division by zero, etc.). More commonly (also in dash and FreeBSD sh), an error inside 'command eval' or 'command .' causes the shell to continue after 'command' with a non-zero $?. This affects an error from 'set -u' but not an exit from 'set -e'. The effect of command on eval and dot is currently hardly specified and differs across shells, but that is for another issue. Consider replacing the description of 'set -u' with: When the shell tries to expand an unset parameter other than the ’@’ and ’*’ special parameters, it shall write a message to standard error and the expansion shall fail. A reference to XCU 2.8.1 Consequences of Shell Errors could be added. The restriction on exit status in 'set -u' (must be between 1 and 125 exclusive) should then be added to "If a command fails during word expansion or redirection," in XCU 2.8.2 Exit Status for Commands. |
(0001673) geoffclare (manager) 2013-07-11 16:40 edited on: 2013-07-18 15:22 |
Updated proposal which incorporates Note: 0001660... At page 2370 line 75508 change: The exit utility shall cause the shell to exit with the exit status specified by the unsigned decimal integer n. to: 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. After page 2371 line 75546 section 2.14 exit add to EXAMPLES: Propagate error handling from within a subshell: ( command1 || exit 1 command2 || exit 1 exec command3 ) > outputfile || exit 1 echo "outputfile created successfully" At page 2337 line 74300 section 2.8.1 change If any of the errors shown as "shall exit" or "(may) exit" occur in a subshell, the subshell shall (respectively may) exit with a non-zero status, but the script containing the subshell shall not exit because of the error. In all of the cases shown in the table, an interactive shell shall write a diagnostic message to standard error without exiting. to: If any of the errors shown as "shall exit" or "(may) exit" occur in a subshell environment, the shell shall (respectively may) exit from the subshell environment with a non-zero status and continue in the environment from which that subshell environment was invoked. In all of the cases shown in the table, an interactive shell shall write a diagnostic message to standard error without exiting and without any further processing of the command in which the error occurred. At page 2337 line 74312 section 2.8.2 change: If a command fails during word expansion or redirection, its exit status shall be greater than zero. to: If a command fails during word expansion or redirection, its exit status shall be between 1 and 125 inclusive. At page 2381 line 75846 section 2.14 set change: the shell immediately shall exit with the following exceptions to: the shell immediately shall exit, as if by executing the exit special built-in utility with no arguments, with the following exceptions At page 2382 line 75903 section 2.14 set change the description of the -u option to: When the shell tries to expand an unset parameter other than the ’@’ and ’*’ special parameters, it shall write a message to standard error and the expansion shall fail with the consequences specified in 2.8.1 Consequences of Shell Errors (on page 2337). |
(0001683) Don Cragun (manager) 2013-07-18 15:18 |
Interpretation response ------------------------ The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- The changes made here make the standard reflect existing practice. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the changes suggested in Note: 0001673. |
(0001805) ajosey (manager) 2013-09-06 04:54 |
Interpretation Proposed 6 Sep 2013 |
(0001895) ajosey (manager) 2013-10-14 13:07 |
Interpretation approved 14 October 2013 |
Issue History | |||
Date Modified | Username | Field | Change |
2013-06-28 09:45 | geoffclare | New Issue | |
2013-06-28 09:45 | geoffclare | Name | => Geoff Clare |
2013-06-28 09:45 | geoffclare | Organization | => The Open Group |
2013-06-28 09:45 | geoffclare | Section | => 2.14 exit |
2013-06-28 09:45 | geoffclare | Page Number | => 2370 |
2013-06-28 09:45 | geoffclare | Line Number | => 75508 |
2013-06-28 09:45 | geoffclare | Interp Status | => --- |
2013-06-30 21:06 | jilles | Note Added: 0001660 | |
2013-07-11 16:40 | geoffclare | Note Added: 0001673 | |
2013-07-18 15:18 | Don Cragun | Interp Status | --- => Pending |
2013-07-18 15:18 | Don Cragun | Final Accepted Text | => See Note: 0001674. |
2013-07-18 15:18 | Don Cragun | Note Added: 0001683 | |
2013-07-18 15:18 | Don Cragun | Status | New => Interpretation Required |
2013-07-18 15:18 | Don Cragun | Resolution | Open => Accepted As Marked |
2013-07-18 15:19 | Don Cragun | Final Accepted Text | See Note: 0001674. => See Note: 0001683. |
2013-07-18 15:19 | Don Cragun | Tag Attached: tc2-2008 | |
2013-07-18 15:22 | geoffclare | Note Edited: 0001673 | |
2013-09-06 04:54 | ajosey | Interp Status | Pending => Proposed |
2013-09-06 04:54 | ajosey | Note Added: 0001805 | |
2013-10-14 13:07 | ajosey | Interp Status | Proposed => Approved |
2013-10-14 13:07 | ajosey | Note Added: 0001895 | |
2015-03-25 12:37 | geoffclare | Relationship added | related to 0000882 |
2019-06-10 08:55 | agadmin | Status | Interpretation Required => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |