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
0001535 [Issue 8 drafts] Shell and Utilities Objection Error 2021-11-18 16:13 2024-06-11 09:12
Reporter kre View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed   Product Version Draft 2.1
Name Robert Elz
Organization
User Reference
Section 2.9.1.1
Page Number 2332
Line Number 75291-75302
Final Accepted Text Note: 0005670
Summary 0001535: Poor description of declaration (all really) utility argument processing
Description XCU 2.9.1.1 (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
a requirement.

   1. [not relevant here]
   2. The words that are not variable assignments or redirections shall be
       expanded.

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
words.

      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
we do...

     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 2.9.1.1...

    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.
Desired Action 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

        export PATH=~/bin:...

where the '~' would not be expanded by a regular expansion, one can
always just write

        PATH=~/bin:...
        export PATH

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
that works.

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 issue8
Attached Files

- Relationships
related to 0000351Closedajosey 1003.1(2008)/Issue 7 certain shell special built-ins should expand arguments in assignment context 
related to 0001785Resolved Issue 8 drafts Conflict in specification of processing of declaration utilities 

-  Notes
(0005670)
geoffclare (manager)
2022-02-10 16:57

Change item 2 from:
The words that are not variable assignments or redirections shall be expanded. 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. If the command name is recognized as a declaration utility, then any remaining words that would be recognized as a variable assignment in isolation shall be expanded as a variable assignment (tilde expansion after the first <equals-sign> and after any unquoted <colon>, parameter expansion, command substitution, arithmetic expansion, and quote removal, but no field splitting or pathname expansion); while words that would not be a variable assignment in isolation shall be subject to regular expansion. For all other command names, all subsequent words shall be subject to regular expansion (tilde expansion for only a leading <tilde>, parameter expansion, command substitution, arithmetic expansion, field splitting, pathname expansion, and quote removal).
to:
The first word (if any) that is not a variable assignment or redirection shall be expanded. If any fields remain following its expansion, the first field shall be considered the command name. If no fields remain, the next word (if any) shall be expanded, and so on, until a command name is found or no words remain. If there is a command name and it is recognized as a declaration utility, then any remaining words after the word that expanded to produce the command name, that would be recognized as a variable assignment in isolation, shall be expanded as a variable assignment (tilde expansion after the first <equals-sign> and after any unquoted <colon>, parameter expansion, command substitution, arithmetic expansion, and quote removal, but no field splitting or pathname expansion); while remaining words that would not be a variable assignment in isolation shall be subject to regular expansion (tilde expansion for only a leading <tilde>, parameter expansion, command substitution, arithmetic expansion, field splitting, pathname expansion, and quote removal). For all other command names, words after the word that produced the command name shall be subject only to regular expansion. All fields resulting from the expansion of the word that produced the command name and the subsequent words, except for the field containing the command name, shall be the arguments for the command.

- Issue History
Date Modified Username Field Change
2021-11-18 16:13 kre New Issue
2021-11-18 16:13 kre Name => Robert Elz
2021-11-18 16:13 kre Section => 2.9.1.1
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
2022-02-10 16:57 geoffclare Note Added: 0005670
2022-02-10 16:57 geoffclare Final Accepted Text => Note: 0005670
2022-02-10 16:57 geoffclare Status New => Resolved
2022-02-10 16:57 geoffclare Resolution Open => Accepted As Marked
2022-02-10 16:57 geoffclare Tag Attached: issue8
2022-02-24 11:53 geoffclare Status Resolved => Applied
2023-10-28 05:08 Don Cragun Relationship added related to 0001784
2023-10-28 06:27 Don Cragun Relationship deleted related to 0001784
2023-10-28 06:27 Don Cragun Relationship added related to 0001785
2024-06-11 09:12 agadmin Status Applied => Closed


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