|Anonymous | Login||2019-07-15 22:45 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001265||[1003.1(2016)/Issue7+TC2] Shell and Utilities||Objection||Error||2019-07-02 11:08||2019-07-03 06:24|
|Organization||The Open Group|
|Section||2.14 (dot, shift, trap)|
|Final Accepted Text|
|Summary||0001265: Knock-on effects of Issue 7 change to XCU 2.8.1|
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.
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||No tags attached.|
|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?|
edited on: 2019-07-02 15:57
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: Note: 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.|
edited on: 2019-07-02 17:53
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.
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.
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
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.|
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|