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
0001391 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2020-08-13 19:58 2021-02-12 16:40
Reporter kre View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
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 Note: 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
this shell, the function shall be invoked as described in Section 2.9.5.
If the implementation has provided a standard utility in the form of a
function, it shall not be recognized at this point. It shall be invoked
in conjunction with the path search in step 1e.


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

If the command name matches the name of a function known to
this shell, the function shall be invoked as described in Section 2.9.5.

and delete the rest, viz:

If the implementation has provided a standard utility in the form of a function,
it shall not be recognized at this point. It shall be invoked in conjunction
with the path search in step 1e.

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:
that standard utility shall not be recognized at this
point, whereas an application defined function of the same name is.


Also be change the word
It

in the following sentence (line 75567) into
Standard utilities implemented as functions
.

I recommend option 1.
Tags tc3-2008
Attached Files

- Relationships
related to 0001390Closed No method to invoke a non-standard built-in utility 
related to 0001389Closed Shell command search procedure is incorrect 

-  Notes
(0004922)
geoffclare (manager)
2020-08-14 09:21
edited on: 2020-08-14 09:24

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.



- Issue History
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 => Note: 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


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