Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001265 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2019-07-02 11:08 2019-12-05 11:15
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
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 Note: 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
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.
(0004503)
nick (manager)
2019-08-01 15:38

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.
(0004599)
agadmin (administrator)
2019-10-07 15:15

Interpretation proposed: 7 October 2019
(0004620)
kre (reporter)
2019-10-15 02:15

This has nothing to do with the resolution of this issue, but re Note: 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 Note: 0004468 (with a typo corrected)

     Anyone who says, or even thinks, that is an idiot.

where "that" referred to Note: 0004467

     some may say $? is required to be zero if it is not considered fatal
(0004626)
shware_systems (reporter)
2019-10-17 18:46

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.
(0004641)
agadmin (administrator)
2019-11-11 12:17

Interpretation Approved: 11 Nov 2019

- 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
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 Note: 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


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