Anonymous | Login | 2024-04-29 06:28 UTC |
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 | ||
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 | ||||||
|
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 |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |