Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
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
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
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 ---
Final Accepted Text
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 No tags attached.
Attached Files

- Relationships

-  Notes
(0004462)
chet_ramey (reporter)
2019-07-02 14:50

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?
(0004463)
shware_systems (reporter)
2019-07-02 15:50
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.

(0004464)
geoffclare (manager)
2019-07-02 16:19

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.
(0004465)
shware_systems (reporter)
2019-07-02 17:37
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.

(0004466)
chet_ramey (reporter)
2019-07-02 18:17

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.
(0004467)
shware_systems (reporter)
2019-07-02 20:00

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.
(0004468)
kre (reporter)
2019-07-03 00:06

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.
(0004469)
shware_systems (reporter)
2019-07-03 06:24

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.

- Issue History
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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker