View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001265 | 1003.1(2016/18)/Issue7+TC2 | Shell and Utilities | public | 2019-07-02 11:08 | 2024-06-11 09:08 |
| Reporter | geoffclare | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Error |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Geoff Clare | ||||
| Organization | The Open Group | ||||
| User Reference | |||||
| Section | 2.14 (dot, shift, trap) | ||||
| Page Number | 2393,2416,2421 | ||||
| Line Number | 76558,77394,77559 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | See 0001265:0004503 | ||||
| Summary | 0001265: Knock-on effects of Issue 7 change to XCU 2.8.1 | ||||
| Description | Between Issue 6 and Issue 7 major changes were made to XCU 2.8.1 "Consequences of Shell Errors". In particular the table used to have a row for "Utility syntax error (option or operand error)" that no longer exists. However, there are uses of "syntax error" in XCU 2.14 which relate to this old table row and should therefore have been updated at the same time, but weren't. | ||||
| Desired Action | On page 2393 line 76558 section 2.14 (dot), change:an interactive shell shall write a diagnostic message to standard error, but this condition shall not be considered a syntax error.to: an interactive shell shall write a diagnostic message to standard error. On page 2416 line 77394 section 2.14 (shift), change: this may be considered a syntax error and a non-interactive shell may exit; if the shell does not exit in this case, a non-zero exit status shall be returned.to: this shall be treated as an error and a non-interactive shell shall exit; in an interactive shell, a non-zero exit status shall be returned. On page 2421 line 77535 section 2.14 (trap), add a new paragraph: If an invalid signal name [XSI]or number[/XSI] is specified, the trap utility shall write a warning message to standard error. On page 2421 line 77552 section 2.14 (trap), change: The standard error shall be used only for diagnostic messages.to: The standard error shall be used only for diagnostic messages and warning messages about invalid signal names [XSI]or numbers[/XSI]. On page 2421 line 77559 section 2.14 (trap), change: For both interactive and non-interactive shells, invalid signal names [XSI]or numbers[/XSI] shall not be considered a syntax error and do not cause the shell to abort.to: For both interactive and non-interactive shells, invalid signal names [XSI]or numbers[/XSI] shall not be considered an error and shall not cause the shell to abort. | ||||
| Tags | tc3-2008 | ||||
|
|
So we're changing the standard to make a numeric argument to shift that is greater than the number of positional parameters a fatal error now? |
|
|
I question this also... Making it explicit a non-zero result is expected for either mode is fine, but the change from may fail to shall fail doesn't appear warranted. The implication is nothing is shifted, if the shell doesn't abort, but some implementations, since the value is large enough, may shift as many as it can, effectively deleting all so $# becomes zero, and the return code is more a warning than an indication something prevented any shifts. The only case I see for considering it a shell fatal syntax error is, after expansions, the argument is a string that is not a decimal number, but even so some implementations may treat this as if zero or no value was supplied so it should stay as may fail. I could see it as a utility, not shell, shall fail case, with a different error number, if there are no parameters to shift at all, even with a zero parameter. This would be a debugging aid to indicate some part of a script, say in a trap action, was removing more parameters than expected. |
|
|
Re: 0001265:0004463 "I could see it as a utility, not shell, shall fail case". That's how I see it - it should be a shift utility shall fail because it is unable to perform the requested operation. However, as Chet points out, with the change of 2.8.1 so that syntax errors are no longer treated differently than other errors, the result of changing this to "shall fail" is that a non-interactive shell is required to exit. |
|
|
I think the standard may be better served to make that "may exit", in Line 75421, or qualify it as to severity in a seperate note, that per utility, non-fatal errors are warnings that don't cause a shell to abort, but still return a non-zero in $?, and these would be still under the general classification of may or shall fail. A "shall exit" would apply for errors not explictly noted as non-fatal. |
|
|
Re: 4464 We're not powerless here: we can certainly say that while an invalid argument constitutes a fatal error, a valid numeric argument that exceeds $# is not. |
|
|
Re: 4466 Yes, but some may say $? is required to be zero if it is not considered fatal, if 2.8.1 stays as it is now, to disable the shell having to exit. What is optional for non-fatal is whether a diagnostic goes to stderr or not. |
|
|
Re bugnote: 4467 "but some may say $? is required to be zero if it is not considered fatal" Anyone who says, or even think,s, that is an idiot. Consider test 1 -eq 0 or grep notfound /some/file/that/exists $? != 0 indicates that the command failed, for whatever definition of failed that command has, and while errors are generally one way a command can fail, there are also numerous others. |
|
|
No, I will not consider those... They are regular utilities, not special built-ins, that allow the application to interpret non-success appropriately, as fatal, warning, or informative, as part of failure recovery, because the shell shall not exit. They are still considered failures, for the boolean question "Did the utility succeed or not?", that applies for "shall exit" now with special built-ins. |
|
|
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 use of the term syntax error makes the requirements here unclear. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the following changes: On page 2393 line 76558 section 2.14 (dot), change: an interactive shell shall write a diagnostic message to standard error, but this condition shall not be considered a syntax error. to: an interactive shell shall write a diagnostic message to standard error. On page 2416 line 77388 section 2.14 (shift), change: The standard error shall be used only for diagnostic messages. to: The standard error shall be used only for diagnostic messages and the warning message specified in EXIT STATUS. On page 2416 line 77394 section 2.14 (shift), change: this may be considered a syntax error and a non-interactive shell may exit; if the shell does not exit in this case, a non-zero exit status shall be returned. to: this may be treated as an error and a non-interactive shell may exit; if the shell does not exit in this case, a non-zero exit status shall be returned and a warning message shall be written to standard error. On page 2421 line 77535 section 2.14 (trap), add a new paragraph: If an invalid signal name [XSI]or number[/XSI] is specified, the trap utility shall write a warning message to standard error. On page 2421 line 77552 section 2.14 (trap), change: The standard error shall be used only for diagnostic messages. to: The standard error shall be used only for diagnostic messages and warning messages about invalid signal names [XSI]or numbers[/XSI]. On page 2421 line 77559 section 2.14 (trap), change: For both interactive and non-interactive shells, invalid signal names [XSI]or numbers[/XSI] shall not be considered a syntax error and do not cause the shell to abort. to: For both interactive and non-interactive shells, invalid signal names [XSI]or numbers[/XSI] shall not be considered an error and shall not cause the shell to abort. |
|
|
Interpretation proposed: 7 October 2019 |
|
|
This has nothing to do with the resolution of this issue, but re 0001265:0004469 (I am just finding time to get back to this). There is nothing special about the exit status of special builtins in general that implies any special relationship with errors, fatal or otherwise (obviously for some special builtins there can be a relationship, though for fatal errors it would only apply for interactive shells). But consider "unset" ... Unsetting a variable or function that was not previously set shall not be considered an error and does not cause the shell to abort. EXIT STATUS 0 All name operands were successfully unset. >0 At least one name could not be unset. where the exit status can be != 0 without there being any kind of error. There is also the dot ('.') command, whose exit status (in the absence of error) is the exit status of the last command executed in the script. And even more obviously, "return" for which the exit status is explicitly anything at all (the argument, or the previous value of $?) when there is no error. So I repeat my statement from 0001265:0004468 (with a typo corrected) Anyone who says, or even thinks, that is an idiot. where "that" referred to 0001265:0004467 some may say $? is required to be zero if it is not considered fatal |
|
|
Re: 4620 With unset, a return > 0 indicates an attempt was made to unset a name marked readonly, not that it wasn't set previously. Such an attempt most consider an attempt at hacking the environment or a name was typo'ed, and so should be fatal. An unset of one or more names that aren't set and aren't reserved as readonly is required to return zero, indicating non-error, or is non-conforming, as the name provided is still unset when the command is done. For the dot and return commands if a non-exit is desired the alternative is to copy the script file into the caller, possibly wrapped in a function. Otherwise dot's primary purpose is to force the shell to abort if the script does not succeed, which includes any return with a non-zero argument. For return in functions it is aborting as fatal the subenvironment setup to execute the function body, so I don't see this as a conflict. |
|
|
Interpretation Approved: 11 Nov 2019 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-07-02 11:08 | geoffclare | New Issue | |
| 2019-07-02 11:08 | geoffclare | Name | => Geoff Clare |
| 2019-07-02 11:08 | geoffclare | Organization | => The Open Group |
| 2019-07-02 11:08 | geoffclare | Section | => 2.14 (dot, shift, trap) |
| 2019-07-02 11:08 | geoffclare | Page Number | => 2393,2416,2421 |
| 2019-07-02 11:08 | geoffclare | Line Number | => 76558,77394,77559 |
| 2019-07-02 11:08 | geoffclare | Interp Status | => --- |
| 2019-07-02 14:50 | chet_ramey | Note Added: 0004462 | |
| 2019-07-02 15:50 | shware_systems | Note Added: 0004463 | |
| 2019-07-02 15:57 | shware_systems | Note Edited: 0004463 | |
| 2019-07-02 16:19 | geoffclare | Note Added: 0004464 | |
| 2019-07-02 17:37 | shware_systems | Note Added: 0004465 | |
| 2019-07-02 17:53 | shware_systems | Note Edited: 0004465 | |
| 2019-07-02 18:17 | chet_ramey | Note Added: 0004466 | |
| 2019-07-02 20:00 | shware_systems | Note Added: 0004467 | |
| 2019-07-03 00:06 | kre | Note Added: 0004468 | |
| 2019-07-03 06:24 | shware_systems | Note Added: 0004469 | |
| 2019-08-01 15:38 | nick | Note Added: 0004503 | |
| 2019-08-01 15:38 | nick | Interp Status | --- => Pending |
| 2019-08-01 15:38 | nick | Final Accepted Text | => See 0001265:0004503 |
| 2019-08-01 15:38 | nick | Status | New => Interpretation Required |
| 2019-08-01 15:38 | nick | Resolution | Open => Accepted As Marked |
| 2019-08-01 15:39 | nick | Tag Attached: tc3-2008 | |
| 2019-10-07 15:15 | agadmin | Interp Status | Pending => Proposed |
| 2019-10-07 15:15 | agadmin | Note Added: 0004599 | |
| 2019-10-15 02:15 | kre | Note Added: 0004620 | |
| 2019-10-17 18:46 | shware_systems | Note Added: 0004626 | |
| 2019-11-11 12:17 | agadmin | Interp Status | Proposed => Approved |
| 2019-11-11 12:17 | agadmin | Note Added: 0004641 | |
| 2019-12-05 11:15 | geoffclare | Status | Interpretation Required => Applied |
| 2024-06-11 09:08 | agadmin | Status | Applied => Closed |
