View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001065 | 1003.1(2013)/Issue7+TC1 | Shell and Utilities | public | 2016-08-09 03:29 | 2017-12-14 16:52 |
| Reporter | izabera | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Rejected | ||
| 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. | ||||
|
|
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. |
|
|
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. |
|
|
Rejected for the reasons stated in 0001065: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. |
|
|
The topic of standardizing 'local' is covered in 0000767 |
|
|
Regarding unspecified behaviour when "local" is used, see XCU 2.9.1.1 Command Search and Execution, item 1. b. |
| 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 |
