Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001785 [Issue 8 drafts] Shell and Utilities Objection Error 2023-10-28 04:09 2023-10-30 14:07
Reporter kre View Status public  
Assigned To
Priority normal Resolution Open  
Status New   Product Version Draft 3
Name Robert Elz
Organization
User Reference
Section XCU 2.9.1.1
Page Number 2483
Line Number 80766-80778, 80790-80792
Final Accepted Text
Summary 0001785: Conflict in specification of processing of declaration utilities
Description In XCU 2.9.1.1 bullet point 2, ut is said:

     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.

All that is fine and boring, then it continues:

     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 [...]

(it goes on to what all of that means, which is not important here).

Note the required sequence, "the first word shall be expanded" ... [If
there is one and] "it is recognised as a declaration utility" ... "shall be
expanded as a variable assignment" ...

There is nothing optional about what is specified there, first expand
the word(s), then having found the command name, check if it (the result
of the expansion) is a declaration utility, and if so do the special processing
that is to be required of such things.

But later, after the bullet points, at lines 80790-80792 (right at the
bottom of page 2483) it says:

    When determining whether a command name is a declaration utility, an
    implementation may use only lexical analysis.

That isn't what the previous text seems to require to me.

    It is unspecified whether assignment context will be used if the
    command name would only become recognized as a declaration utility
    after word expansions.

To me, that looks to be very explicitly specified, as quoted above.
Desired Action Reconcile this nonsense.

Best would be to delete the notion of "declaration utilities" completely,
or at least make them optional (unspecified whether such things work).

They're never needed, one can always simply write

    export FOO
    FOO=whatever-I-like

and the assignment will be handled as a var-assign, without any magic
special rules (those two statements can be written in either order, except
for "readonly" where the assignment must come first), or if you prefer,
the following also works

    FOO=whatever-I-like export FOO

if you really need to do it all in one statement.

This declaration utility nonsense (the special rules for arg processing)
were added just to pacify people who don't understand the order in which
the shell parses commands in general, and the syntax of the parts. What's
more, including it, then leads to people wondering why (if we assume
a file named "foo bar" (without the quotes) exists in '.'

    dd if=~/foo* ...
or
    awk -v var=foo* ...

aren't parsed the same way, after all, they look just the same, your
average shell command line user has no idea what a "declaration utility"
might be. Must easier to explain that the special rules for things which
look like (and always are) var-assigns apply only to those which appear
before the command name, as soon as there is anything (other than a redirect)
all the special processing stops.

But in any case, this "shall do ..." followed immediately by "may be done
differently" needs to be fixed, one way or the other - either change bullet
point 2 to make all of what it says about finding declaration utilities
optional, or simply remove lines 90790-2, and require it to be implemented
as in bullet point 2.

[Aside: none of this means much to me, I have no intention of implementing
"declaration utilities" whichever scheme were to be adopted.]
Tags No tags attached.
Attached Files

- Relationships
related to 0001535Applied Issue 8 drafts Poor description of declaration (all really) utility argument processing 
related to 0001393Applied Issue 8 drafts 'command' should not be treated as a declaration utility 
related to 0000351Appliedajosey 1003.1(2008)/Issue 7 certain shell special built-ins should expand arguments in assignment context 

-  Notes
(0006557)
kre (reporter)
2023-10-28 05:48

 This issue is very much related to 0001535 (the resolution to which
was applied in Feb 2022, which is well before Issue 8 Draft 3, so the
text from that bug resolution is what was considered here).

In 0001535 I pointed out this contradictory text, but that part of
the issue was completely ignored... It still needs fixing.
(0006559)
chet_ramey (reporter)
2023-10-30 14:07

 Look at issue 1393 for a discussion about why it's acceptable to recognize such names lexically: so the parser can allow extended assignment syntax such as compound array assignment.

Since the NetBSD sh doesn't have those, you can ignore it.

- Issue History
Date Modified Username Field Change
2023-10-28 04:09 kre New Issue
2023-10-28 04:09 kre Name => Robert Elz
2023-10-28 04:09 kre Section => XCU 2.9.1.1
2023-10-28 04:09 kre Page Number => 2483
2023-10-28 04:09 kre Line Number => 80766-80778, 80790-80792
2023-10-28 05:48 kre Note Added: 0006557
2023-10-28 06:27 Don Cragun Relationship added related to 0001535
2023-10-28 06:28 Don Cragun Relationship added related to 0001393
2023-10-28 06:30 Don Cragun Relationship added related to 0000351
2023-10-30 14:07 chet_ramey Note Added: 0006559

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