Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001065 [1003.1(2013)/Issue7+TC1] Shell and Utilities Editorial Clarification Requested 2016-08-09 03:29 2017-12-14 16:52
Reporter izabera View Status public  
Assigned To
Priority normal Resolution Rejected  
Status Closed  
Name Isabella
Organization
User Reference
Section (section number or name, can be interface name)
Page Number (page or range of pages)
Line Number (Line or range of lines)
Interp Status ---
Final Accepted Text
Summary 0001065: Clarification request on invocations
Description What should happen when utilites are invoked with unspecified options?
And what should happen with unspecified commands?

I have a couple of examples in mind:

- gnu true
$ /bin/true --help >&-; echo $?
/bin/true: write error: Bad file descriptor
1

- local
$ f() { local x; x=1; }; x=2; f; echo $x
2



true is returning 1, but the exit status section in the standard clearly
states "Zero."
The synopsis for true only specifies invocations with no arguments.
Am I understanding correctly that the behaviour of any invocation with
arguments is unspecified?



local is not specified, and it's turning sh variables into magic things
that don't follow the rules of sh variables anymore.
Is it correct that the standard doesn't apply in this case because local
is not a standard utility?
If so, does the standard specify what should happen in this case?

cd /bin; ./echo x

I'm invoking a command named ./echo which isn't specified.

What about this case?

cd "$(dirname "$(command -v ls)")" && ./ls /



(This has probably been discussed in the past but I couldn't find it).
Desired Action Please clarify, thanks.
Tags No tags attached.
Attached Files

- Relationships
related to 0000767Closedajosey 1003.1(2008)/Issue 7 Add built-in "local" 

-  Notes
(0003329)
shware_systems (reporter)
2016-08-10 13:04
edited on: 2016-08-10 13:06

 Per XCU 1.4:

Unless otherwise stated in the utility description, when given an option unrecognized
by the implementation, or when a required option-argument is not provided, standard
utilities shall issue a diagnostic message to standard error and exit with a non-zero exit
status.

That true implementation is respecting this clause, it appears, by returning 1. It could be argued the error message should be "unrecognized operand: --help" in conforming mode, in addition to the pipe error. The errors section in a utility description are more in addition to generic errors like this, as I read it, as things that can occur even with operands and options being of valid form.

The criteria for applications is covered in XBD 2.2 and 12, and XCU 1; and as extension shell Reserved Words in XCU 2.4 (which local usually is, or a special built-in covered by XCU 2.9). The standard requires on disk versions of built-in utilities to behave as in the standard in the primary utilities directory. When stored in other directories they are simply applications with the same base name as a utility. In conforming mode a conforming application, with or without extensions, should respect that clause also; otherwise yes, the behavior is unspecified but usually documented somehow. When not in conforming mode any extensions such as "--help" may be enabled, again with unspecifiable behavior.
(0003361)
eblake (manager)
2016-08-25 15:29

 The general use of '--help' is unspecified; applications can do whatever they want with it (the two most common behaviors are to reject the second '-' as an unknown short option character, or to display help text, but there is no required behavior). Remember, XBD 12.2 guideline 3 states that an option must have an alphanumeric character after the '-', but '--help' does not fit that bill; and the standard then goes on to state that the guidelines are requirements on standard utilities that do not specify otherwise (and true does not specify otherwise); but also specifically allows for extensions: "On some implementations, the utilities accept usage in violation of these guidelines for backwards-compatibility as well as accepting the required form."

GNU's 'true --help' behavior is not specified by the standard, because the mere use of '--help' puts the usage outside the realm of defined behavior. Once you invoke an application with arguments that do not have specified behavior, you are no longer guaranteed a particular exit status. Likewise, you are correct in noting that even 'true garbage' is undefined behavior by the standard for passing an argument where the standard did not document one as permitted, and thus is not portably required to have exit status 0. The whole point of unspecified options is that they are unspecified, and we cannot portably define behavior for them.
(0003899)
Don Cragun (manager)
2017-12-14 16:42
edited on: 2017-12-14 16:53

 Rejected for the reasons stated in Note: 0003361.

Also note that the behavior of:
cd /bin; ./echo abc

is unspecified by the standard because there is no requirement that the standard echo utility be located in a directory named /bin.
(0003900)
eblake (manager)
2017-12-14 16:44

 The topic of standardizing 'local' is covered in 0000767
(0003901)
geoffclare (manager)
2017-12-14 16:52

 Regarding unspecified behaviour when "local" is used, see XCU 2.9.1.1 Command Search and Execution, item 1. b.

- Issue History
Date Modified Username Field Change
2016-08-09 03:29 izabera New Issue
2016-08-09 03:29 izabera Name => Isabella
2016-08-09 03:29 izabera Section => (section number or name, can be interface name)
2016-08-09 03:29 izabera Page Number => (page or range of pages)
2016-08-09 03:29 izabera Line Number => (Line or range of lines)
2016-08-10 13:04 shware_systems Note Added: 0003329
2016-08-10 13:06 shware_systems Note Edited: 0003329
2016-08-25 15:29 eblake Note Added: 0003361
2017-12-14 16:42 Don Cragun Note Added: 0003899
2017-12-14 16:43 Don Cragun Interp Status => ---
2017-12-14 16:43 Don Cragun Status New => Closed
2017-12-14 16:43 Don Cragun Resolution Open => Rejected
2017-12-14 16:44 eblake Relationship added related to 0000767
2017-12-14 16:44 eblake Note Added: 0003900
2017-12-14 16:50 Don Cragun Note Edited: 0003899
2017-12-14 16:51 Don Cragun Note Edited: 0003899
2017-12-14 16:52 geoffclare Note Added: 0003901
2017-12-14 16:52 Don Cragun Note Edited: 0003899
2017-12-14 16:53 Don Cragun Note Edited: 0003899

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