|Anonymous | Login||2021-12-07 23:29 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001535||[Issue 8 drafts] Shell and Utilities||Objection||Error||2021-11-18 16:13||2021-11-19 09:45|
|Status||New||Product Version||Draft 2.1|
|Final Accepted Text|
|Summary||0001535: Poor description of declaration (all really) utility argument processing|
XCU 22.214.171.124 (in Issue 8 Draft 2.1) says:
When a given simple command is required to be executed [...]
the following expansions, assignments, and redirections shall all
be performed from the beginning of the command text to the end:
All that's relevant about that quote is that it makes the ordering
1. [not relevant here]
2. The words that are not variable assignments or redirections shall be
That's simple enough. The first thing we do (after moving redirects
and var-assigns out of the way - that's step 1 - is to expand the remaining
If any fields remain following their expansion, the first field shall
be considered the command name and remaining fields are the arguments
for the command.
This is where we get the command name, and it comes "following their [the
words] expansion" (assuming there are remaining fields, which for this issue
we shall do).
If the command name is recognized as a declaration utility,
At this point we look and see if we have a declaration utility, and if
then any remaining words that would be recognized as a variable
assignment in isolation shall be expanded as a variable assignment
then we must look at the remaining (remember already expanded) words to
see if any look like a variable assignment, and if we find any, expand
them *again* (as variable assignments - the following (parenthesised)
text goes into what that means, but that's not relevant here.
while words that would not be a variable assignment
in isolation shall be subject to regular expansion.
and the other words also get expanded again, the regular way.
For all other command names,
that is, commands that are not declaration utilities
all subsequent words shall be subject to regular expansion
all the remaining words just get regular expansion (this is followed by
an explanation of what "regular expansion" means - not relevant here -
except to note in passing that this is the second occurrence of "regular
expansion", the first one didn't get explained - that's probably backwards.
That is, the words are expanded, the command name (first non-empty remaining
field) gets examined, and depending upon what we see, we expand all the
other args again in one way or another.
That's not how it is supposed to happen - not in anyone's world view.
Further, with this (precisely specified order of processing) this final
paragraph of 126.96.36.199...
When determining whether a command name is a declaration utility, an
implementation may use only lexical analysis.
It isn't really clear what that means, but lexical analysis is occurring
around the same time as alias expansion, so how the two interact would
probably need to be made clear, but this probably doesn't matter anyway
(or not with the current wording) as:
It is unspecified whether assignment context will be used if the
command name would only become recognized as a declaration utility
after word expansions.
No it isn't, it is very precisely specified, as above - the word expansions
happen first, and then the result is examined to determine whether the command
name is a declaration utility or not. Nothing even slightly unspecified
about that, and adding contradictory text here can only confuse things.
Rewrite this nonsense into something that makes sense. Nothing is ever
expanded twice (other than via eval or similar) in the shell, once is all
anyone ever gets.
While doing that, make it unspecified whether any particular commands are
declaration utilities - I can understand why people want them, and know
that some shells implement this, but it is all new in the standard, and
other shells do not (some *never* will). Further, the concept is absolutely
not required for anything, instead of
where the '~' would not be expanded by a regular expansion, one can
always just write
which works, with no changes to the standard, in every shell. It even
worked back when assignments in the export (etc) commands didn't work at all.
This is the way that applications should be advised to code, the safe way
Then shells that want to extend the syntax of these commands should be allowed
to do so, and applications should be warned that if this kind of modified
expansion is not desired, they should make sure to always quote the arguments
to these commands (which will prevent any of this magic expansions, as a
quoted "PATH=..." does not have the correct form for a variable assignment,
the name= part must be unquoted.
|Tags||No tags attached.|
|There are no notes attached to this issue.|
|2021-11-18 16:13||kre||New Issue|
|2021-11-18 16:13||kre||Name||=> Robert Elz|
|2021-11-18 16:13||kre||Section||=> 188.8.131.52|
|2021-11-18 16:13||kre||Page Number||=> 2332|
|2021-11-18 16:13||kre||Line Number||=> 75291-75302|
|2021-11-19 09:45||geoffclare||Relationship added||related to 0000351|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|