Anonymous | Login | 2024-12-12 16:11 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 | ||
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 | |||||||||||||
|
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 |