View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001391 | 1003.1(2016/18)/Issue7+TC2 | Shell and Utilities | public | 2020-08-13 19:58 | 2024-06-11 09:08 |
| Reporter | kre | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Error |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Robert Elz | ||||
| Organization | |||||
| User Reference | |||||
| Section | 2.9.1.1 1.c (2.9.1.4 1.c in Issue 8 draft 1) | ||||
| Page Number | 2367 (2294 in Issue 8 draft 1) | ||||
| Line Number | 75564-7 (74159-62 in Issue 8 draft 1) | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0001391:0004922 | ||||
| Summary | 0001391: Unclear language in specification of utilities implemented as functions | ||||
| Description | I do not believe there is likely to be any disagreement over what should be done here, though there may be some over whether the current language is unclear. My opinion on that is that if anyone can reasonably read the text in a way different from what is intended, and if it is easily possible to correct the text to improve clarity, then that should always be done. Anyway, 2.9.1.1 1.c (unchanged in Issue 8, other than the section number) states If the command name matches the name of a function known to While this is somewhat fanciful, as to the best of my knowledge, no shell implements any standard utilities as functions, the issue is if the shell did implement some standard utility as a function (something like dirname might be a possibility) and the user (application) has also defined a function of the same name (overriding the implementation provided definition), what should happen. My expectation is that the "If the implementation has provided a standard utility in the form of a function, it shall not be recognized at this point." text means that the standard utility, implemented as a function, should not be recognised, but that a user defined function of the same name still should be. However, it is not unreasonable to read it as prohibiting (at this point) invoking any function with the same name as that of a standard utility implemented as a function ("it shall not be recognized at this point", is the antecedent of "it" the "command name" or the "standard utility implemented as a function". While the latter is almost certainly what was intended, either is actually a justifiable reading of the text. This becomes problematic, as if a user defined function is not invoked in 2.9.1.1 1.c then it never is, as 2.9.1.1 1.e.i only allows for two cases, a where "If the system has implemented the utility as a built-in or as a shell function, ..." or b "Otherwise, the shell executes the utility in a separate utility environment" (the text here has altered in Issue 8 draft 1, but the effect is the same). Neither of those allow invoking a user defined function. Further, it would be strange if any user defined function (regardless of its name) depended upon a successful PATH search before it could be invoked. Clarifying the language of 2.9.1.1 1.c will avoid this problem. Note that if the resolution of 0001389 is to accept the proposed text, or something substantially similar, then this issue becomes moot, as all references to standard utilities implemented as functions will have been removed, leaving 2.9.1.1 1.c simply specifying the invocation of a function. It should also be noted, that while the standard attempts to specify what should be done with standard utilities implemented as functions, it is not actually documenting any known standard behaviour there, as there are no known (to me anyway) instances of standard utilities implemented as functions. Rather than documenting the standard behaviour, what happened is an attempt to specify how such things should behave, if any ever were to exist. That's not the standard, that's a flight of fancy. | ||||
| Desired Action | Option 1. In section 2.9.1.1 1.c (2.9.1.4 1.c in Issue 8 draft 1) delete all after the first sentence. That is retain
and delete the rest, viz:
It would also probably make sense to delete the reference to standard utilities implemented as functions from 2.9.1.1 1.e but that is not essential for the purposes of this issue. This option recognises that absent implementation, it is premature to standardise the behaviour of standard utilities implemented as functions, as no-one has any idea what that behaviour would be. Option 2: In 2.9.1.1 1.c change the words: it shall not be recognized at this point.to: | ||||
| Tags | tc3-2008 | ||||
|
|
I think there is a misunderstanding here of what "If the implementation has provided a standard utility in the form of a function" means. The description talks about "if the shell did implement some standard utility as a function" which has implications that are not quite the same. I believe the thinking behind "the implementation has provided a standard utility in the form of a function" is that an implementation could define a function in an implementation-provided shell startup file. Some implementations do this with aliases (such as the misguided alias rm='rm -i'); the standard allows a similar thing with functions. I suppose a function could also be predefined internally by the shell itself. However, the crucial thing is that it is just a function definition like any other; it is not special (other than being already defined by the time the shell reads commands from the user/script, and the requirement about when it is recognised). So if the application defines a function of the same name, it simply replaces the one provided by the implementation. The application could also delete the function using "unset -f". I think a suitable change to clarify this would be to change: If the implementation has provided a standard utility in the form of a function, it shall not be recognized at this point.to: If the implementation has provided a standard utility in the form of a function, and that function definition still exists (i.e. has not been removed using unset -f or replaced via another function definition with the same name), it shall not be recognized at this point. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-08-13 19:58 | kre | New Issue | |
| 2020-08-13 19:58 | kre | Name | => Robert Elz |
| 2020-08-13 19:58 | kre | Section | => 2.9.1.1 1.c (2.9.1.4 1.c in Issue 8 draft 1) |
| 2020-08-13 19:58 | kre | Page Number | => 2367 (2294 in Issue 8 draft 1) |
| 2020-08-13 19:58 | kre | Line Number | => 75564-7 (74159-62 in Issue 8 draft 1) |
| 2020-08-13 21:18 | Don Cragun | Relationship added | related to 0001389 |
| 2020-08-13 21:19 | Don Cragun | Relationship added | related to 0001390 |
| 2020-08-14 08:31 | geoffclare | Interp Status | => --- |
| 2020-08-14 08:31 | geoffclare | Description Updated | |
| 2020-08-14 09:21 | geoffclare | Note Added: 0004922 | |
| 2020-08-14 09:24 | geoffclare | Note Edited: 0004922 | |
| 2021-01-28 17:18 | geoffclare | Final Accepted Text | => 0001391:0004922 |
| 2021-01-28 17:18 | geoffclare | Status | New => Resolved |
| 2021-01-28 17:18 | geoffclare | Resolution | Open => Accepted As Marked |
| 2021-01-28 17:19 | geoffclare | Tag Attached: tc3-2008 | |
| 2021-02-12 16:40 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 09:08 | agadmin | Status | Applied => Closed |
