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
0001091 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Error 2016-10-18 11:55 2016-10-27 18:19
Reporter Mark_Galeck View Status public  
Assigned To
Priority normal Resolution Withdrawn  
Status Closed  
Name Mark Galeck
Organization
User Reference
Section 2.10.1 Shell Grammar Lexical Conventions
Page Number 2375
Line Number 75895-75896
Interp Status ---
Final Accepted Text
Summary 0001091: Some "WORD tokens" do not have "the associated command"
Description It says
"WORD tokens shall have the word expansion rules applied to them immediately before the associated command is executed"

For some WORD tokens, there is no "associated command".

It is not defined what "associated command" means, but let's say we assume in the broadest sense, that when we execute a simple command as if by execl(), then that is "associated" with any WORDs in the arguments to execl and the global environ variable.

Even then, there are some WORDs without an associated command. In fact, in some cases, it is explicitly mentioned to either not perform WORD expansion "immediately before" any particular command execution, but earlier, or even, to not perform a full WORD expansion at all.

In fact, when and if, the WORD expansion is to be performed, is already covered, in all cases, in specific sections of the standard.
Desired Action Delete the sentence "The WORD tokens shall have the word expansion rules applied to them immediately before the
associated command is executed, not at the time the command is parsed."
Tags No tags attached.
Attached Files

- Relationships
duplicate of 0001100Closed Rewrite of Section 2.10 Shell Grammar, of the Shell Standard, to fix previous reports, fix new issues, and improve presentation. 

-  Notes
(0003419)
geoffclare (manager)
2016-10-18 14:48

The purpose of this piece of text is to specify that word expansion happens not at the time the input is parsed, but later on. If it is unclear what "associated command" means, then the text should be clarified. It should not just be deleted.

The grammar has a production called "command" (line 76015) - so the obvious interpretation of "associated command" in the context of the shell grammar is as a reference to this production.
(0003421)
Mark_Galeck (reporter)
2016-10-18 15:04

Let's not confuse different topics. If you want to make another report that "associated command" is unclear, you are welcome to. I don't. My report is about something else, and the reason why I mentioned "associated command" was not defined, was so that I could take the "broadest" possible interpretation.

I am also not arguing what the purpose of this piece was. I know that very well.

My report is about something else, and that is, the text in question is erroneous (regardless of what its purpose is).

Now, we come to your second paragraph. If that were the meaning of "associated command", then, note that one kind of command, for example, is "brace_group". So we would have to know what it means to "execute" a brace group. Well, there is no such notion. Indeed, if we tried to make it work, we would have to expand all WORD tokens inside a brace group, before "executing" the brace group, which clearly does not make sense.
(0003425)
Mark_Galeck (reporter)
2016-10-18 15:28

Of course I don't want to delete stuff that may be in error. Some time ago my boss asked some junior engineers to "remove warnings" - they proceeded to remove the lines of code that caused warnings. Voila! No warnings, boss!

My contention is that this sentence, which I think is in error, is also not needed, because the standard already precisely specifies when (and, in some cases, "if") the WORD is to be expanded.
(0003428)
geoffclare (manager)
2016-10-18 15:55

I think the problem here is in the definition of the term "execute" (XBD 3.155):

   To perform command search and execution actions, ...

This appears to constrain the use of "execute" only to simple commands, but there are many places where the standard talks about the shell "executing" commands that are not simple commands.

Brace group may not be able to have any expansions associated with it, but there are other non-simple commands which can, such as case, for, etc. I don't think most readers of the standard would have a problem understanding what it means for the shell to "execute" this command:

    for i in $list; do echo "$i"; done

(if they ignore XBD 3.155). When $list is expanded, the "associated command" is the for command.
(0003429)
Mark_Galeck (reporter)
2016-10-19 04:44

Yes, and as I said in the report, there is no need to invoke any "associated command" to "for loop" or anything else. For loop, in its own section, already explains how and when to expand WORDs found during its parsing. Same with every other instance of WORD.

Also, I repeat, in some cases (see for example my two previous reports, which were bogus, yes, but they contained "incomplete" word expansions), there is no such thing as "WORD tokens shall have the word expansion rules applied...". This is simply not true, regardless of when the expansion happens, because for some WORDs, all the steps in "word expansion" are not performed.

Since I just repeated what I already said, I don't see how I can add to the discussion. If you still don't understand what I am saying, and what this report is about, there is nothing more I can explain better, so I will just shut up.
(0003430)
kre (reporter)
2016-10-19 05:51

I think the issue is not what should be done, but when it should be done.
Most of your (Mark's) points have been about adding precision to the spec.
Here, you're suggesting removing it (though probably not intentionally).

Eg: to use the for loop example, the text in 2.9.4.2 says ...

     First, the list of words following in shall be expanded to generate
     a list of items. Then, the ...

That's certainly probably sufficient to say what should be done, though it
(without any assistance) would be a little wishy washy on exactly which
expansions are expected to apply.

But it says to do it "first" - which clearly means before executing the
list of commands with the var set to each value in turn (that's the "Then,
the ..." that I didn't bother quoting as it isn't directly relevant here.

But it puts no initial bound on exactly when the expansion should happen,
just provided it happens before the list is (repeatedly) executed. With
only those words, an implementation may feel free to expand the words as
they are parsed, for example.

That's what the text under question is trying to avoid - it makes it clear
that the expansion is to happen as late as possible before the values are
needed - and while the words it uses to say that might not be the best
possible, and could perhaps be improved, simply deleting them is not the
solution.
(0003468)
Mark_Galeck (reporter)
2016-10-27 12:46

This report can be cancelled.
(0003479)
Don Cragun (manager)
2016-10-27 18:19

Withdrawn by submitter in Note: 0003468

- Issue History
Date Modified Username Field Change
2016-10-18 11:55 Mark_Galeck New Issue
2016-10-18 11:55 Mark_Galeck Name => Mark Galeck
2016-10-18 11:55 Mark_Galeck Section => 2.10.1 Shell Grammar Lexical Conventions
2016-10-18 11:55 Mark_Galeck Page Number => 2375
2016-10-18 11:55 Mark_Galeck Line Number => 75895-75896
2016-10-18 14:48 geoffclare Note Added: 0003419
2016-10-18 15:04 Mark_Galeck Note Added: 0003421
2016-10-18 15:28 Mark_Galeck Note Added: 0003425
2016-10-18 15:55 geoffclare Note Added: 0003428
2016-10-19 04:44 Mark_Galeck Note Added: 0003429
2016-10-19 05:51 kre Note Added: 0003430
2016-10-27 12:46 Mark_Galeck Note Added: 0003468
2016-10-27 18:19 Don Cragun Interp Status => ---
2016-10-27 18:19 Don Cragun Note Added: 0003479
2016-10-27 18:19 Don Cragun Status New => Closed
2016-10-27 18:19 Don Cragun Resolution Open => Withdrawn
2018-04-12 15:39 eblake Relationship added duplicate of 0001100


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