View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000114 | 1003.1(2008)/Issue 7 | Shell and Utilities | public | 2009-07-01 16:55 | 2013-04-16 13:06 |
| Reporter | eblake | Assigned To | ajosey | ||
| Priority | normal | Severity | Comment | Type | Omission |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Eric Blake | ||||
| Organization | |||||
| User Reference | ebb.dot | ||||
| Section | dot | ||||
| Page Number | 2341 | ||||
| Line Number | 74053 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | 0000114:0000257 | ||||
| Summary | 0000114: dot exit status | ||||
| Description | The standard is unclear what happens to $? when an argument to . is not found in an interactive shell. Line 74030 states that a diagnostic is written but it is not a syntax error (which generally implies non-zero status), but line 74053 states that the exit status is 0 if no command is executed (and since no file was found, no command was executed). Existing practice is that $? is set to non-zero in this case (although various shells have chosen 1, 2, or 127). In a similar vein, the standard appears to be silent on what happens when ., eval, or trap encounter text that cannot be parsed in isolation. In this case, traditional shells either aborted with non-zero status, or guaranteed non-zero status visible to subsequent commands; but some modern shells do not detect the failure (which can be rather surprising): $ echo 'if' > tmp $ zsh -c 'emulate sh; . ./tmp; echo $?' ./tmp:1: parse error near `\n' 0 $ bash --posix -c 'trap "if" 0'; echo $? bash: exit trap: line 1: syntax error: unexpected end of file 0 It would be nice to tighten this up (even though that renders some existing implementations buggy). | ||||
| Desired Action | At line 74053 (dot), replace: Returns the value of the last command executed, or a zero exit status if no command is executed. with: If no readable file was found or if the commands in the file could not be parsed, and the shell does not abort, the exit status shall be non-zero. Otherwise, return the value of the last command executed, or a zero exit status if no command is executed. At line 74110 (eval), replace: If there are no arguments, or only null arguments, eval shall return a zero exit status; otherwise, it shall return the exit status of the command defined by the string of concatenated arguments separated by <space> characters. with: If there are no arguments, or only null arguments, eval shall return a zero exit status; otherwise, it shall return the exit status of the command defined by the string of concatenated arguments separated by <space> characters, or a non-zero exit status if the concatenation could not be parsed as a command and the shell did not abort. At line 74864 (trap), replace: The value of "$?" after the trap action completes shall be the value it had before trap was invoked. with: If a trap action cannot be parsed at the time it is invoked, and the shell does not abort, then the value of "$?" shall be non-zero; otherwise the value of "$?" after the trap action completes shall be the value it had before the trap action was invoked. | ||||
| Tags | tc1-2008 | ||||
|
|
This item was reviewed at the 13 August 2009 teleconference. The changes proposed to dot and eval appear acceptable. Some reservations were noted with the trap replacement text. Some further investigations are required . Action on Andrew to contact Dave Korn for feedback. |
|
|
From David Korn: The wording is somewhat ambiguous, but the intent was not. In Bourne shell and ksh88, if a readable file is not found, this is an error. With an interactive script it is fatal and with an interactive script it is not. Since it is an error, it must have a non-zero exit status. It is not a syntax error therefore cannot be found with sh -n. The Exit Status line refers to the case where the file is readable. If the file is empty (or just comments), and therefore no command is executed, then the exit status will be zero. It would make no sense for a command that terminates due to an error to return a zero exit status. One could argue that the exit status should be 127 in the case the file file was not foud, and 126 if it is not readable, but this would represent a change. As far as the proposed change: The proposed change for dot is incorrect in that an interactive script will abort if the file is not found or is not readable as currently described. In the case that the . script has a syntax error, I don't think that the shell should abort, but this is debatable. For eval, a syntax error should cause eval to have a non-zero exit status. I would eliminate "and the shell did not abort". I don't know why eval should cause the shell to abort. For trap, the value of $? after the trap should be the value before the trap so a syntax error would not effect $? I don't understand why the shell would abort. I don't think that a syntax error should effect the value of $?. It doesn't with historical practice. David Korn dgk@research.att.com |
|
|
Geoff Clare responded: >> The proposed change for dot is incorrect in that an interactive script >> will >> abort if the file is not found or is not readable as currently >> described. Presumably David meant to say non-interactive here. The requirement for a non-interactive shell to abort when a dot file is not found is in 2.8.1 Consequences of Shell Errors. (We should probably change it to say "not found or not readable".) So the proposed change is not actually wrong, it's just that the "and the shell does not abort" part only applies to interactive shells. Having said that, it might be better to word it so that it is not misleading to readers not familiar with 2.8.1. >> In the case that the . script has a syntax error, I don't think that >> the shell should abort, but this is debatable. 2.8.1 requires a non-interactive shell to abort. >> For eval, a syntax error should cause eval to have a non-zero exit >> status. >> I would eliminate "and the shell did not abort". I don't know why >> eval >> should cause the shell to abort. Again, 2.8.1 requires a non-interactive shell to abort. Most of the shells I tried do abort, but ksh93 and bash don't. >> For trap, the value of $? after the trap should be the value before >> the trap so a syntax error would not effect $? >> I don't understand why the shell would abort. I don't think that a >> syntax >> error should effect the value of $?. It doesn't with historical >> practice. This confirms the misgivings we had that prompted us to ask David about it, so I believe we should omit the trap part of the changes. Regards, Geoff. |
|
|
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: ------------- None. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- At line 74053 (dot), replace: Returns the value of the last command executed, or a zero exit status if no command is executed. with: If no readable file was found or if the commands in the file could not be parsed, and the shell is interactive (and therefore does not abort; see [xref to 2.8.1]), the exit status shall be non-zero. Otherwise, return the value of the last command executed, or a zero exit status if no command is executed. At line 74110 (eval), replace: If there are no arguments, or only null arguments, eval shall return a zero exit status; otherwise, it shall return the exit status of the command defined by the string of concatenated arguments separated by <space> characters. with: If there are no arguments, or only null arguments, eval shall return a zero exit status; otherwise, it shall return the exit status of the command defined by the string of concatenated arguments separated by <space> characters, or a non-zero exit status if the concatenation could not be parsed as a command and the shell is interactive (and therefore did not abort). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-07-01 16:55 | eblake | New Issue | |
| 2009-07-01 16:55 | eblake | Status | New => Under Review |
| 2009-07-01 16:55 | eblake | Assigned To | => ajosey |
| 2009-07-01 16:55 | eblake | Name | => Eric Blake |
| 2009-07-01 16:55 | eblake | User Reference | => ebb.dot |
| 2009-07-01 16:55 | eblake | Section | => dot |
| 2009-07-01 16:55 | eblake | Page Number | => 2341 |
| 2009-07-01 16:55 | eblake | Line Number | => 74053 |
| 2009-08-13 16:07 | ajosey | Interp Status | => --- |
| 2009-08-13 16:07 | ajosey | Note Added: 0000195 | |
| 2009-10-15 15:07 | nick | Note Added: 0000255 | |
| 2009-10-15 15:08 | nick | Note Added: 0000256 | |
| 2009-10-15 15:15 | geoffclare | Note Added: 0000257 | |
| 2009-10-15 15:21 | geoffclare | Note Edited: 0000257 | |
| 2009-10-15 15:23 | geoffclare | Interp Status | --- => Pending |
| 2009-10-15 15:23 | geoffclare | Final Accepted Text | => 0000114:0000257 |
| 2009-10-15 15:23 | geoffclare | Status | Under Review => Interpretation Required |
| 2009-10-15 15:23 | geoffclare | Resolution | Open => Accepted As Marked |
| 2009-11-07 07:36 | ajosey | Interp Status | Pending => Proposed |
| 2009-12-07 16:57 | ajosey | Interp Status | Proposed => Approved |
| 2010-09-21 11:07 | geoffclare | Tag Attached: tc1-2008 | |
| 2011-05-16 09:14 | geoffclare | Relationship added | related to 0000443 |
| 2013-04-16 13:06 | ajosey | Status | Interpretation Required => Closed |
