|Anonymous | Login||2021-08-01 14:09 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|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|
|Priority||normal||Resolution||Accepted As Marked|
|Section||220.127.116.11 1.c (18.104.22.168 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)|
|Final Accepted Text||Note: 0004922|
|Summary||0001391: Unclear language in specification of utilities implemented as functions|
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, 22.214.171.124 1.c (unchanged in Issue 8, other than the section number)
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
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 126.96.36.199 1.c then it never is, as 188.8.131.52 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 184.108.40.206 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 220.127.116.11 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.
In section 18.104.22.168 1.c (22.214.171.124 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 126.96.36.199 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.
In 188.8.131.52 1.c change the words:
it shall not be recognized at this point.to:
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.
|2020-08-13 19:58||kre||New Issue|
|2020-08-13 19:58||kre||Name||=> Robert Elz|
|2020-08-13 19:58||kre||Section||=> 184.108.40.206 1.c (220.127.116.11 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|