View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001955 | 1003.1(2024)/Issue8 | Shell and Utilities | public | 2025-11-10 18:02 | 2025-11-11 16:19 |
| Reporter | luna | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Under Review | Resolution | Open | ||
| Name | Luna | ||||
| Organization | |||||
| User Reference | |||||
| Section | 2.6.3 | ||||
| Page Number | 2489 | ||||
| Line Number | 80775 | ||||
| Interp Status | |||||
| Final Accepted Text | |||||
| Summary | 0001955: Behaviour is unclear when a parameter expands to another valid expansion | ||||
| Description | In the following shell transcript ``` $ whoami john $ x='`whoami`' $ echo $x ``` I am unable to find clear normative text that would specify whether it should print "`whoami`" or "john". Section 2.6.3 "Command substitution" says "Command substitution shall occur when command(s) are enclosed as follows". Experiments on NetBSD show that `sh(1)` and `bash(1)` in posix mode print "`whoami`", while bash in regular mode prints 'john' | ||||
| Desired Action | I suggest one of the following clarifications: 1. that the command substitution must be in the original word 2. specify in parameter expansion that the results are not command substituted | ||||
| Tags | No tags attached. | ||||
|
|
Oops, I accidentally set this to the 2004 version. I'll clarify that this is referring to the 2024 standard. |
|
|
Isn’t the behaviour clearly defined via at last 2.2.2 Single-Quotes?! |
|
|
Thats not exactly what I'm referring to. Heres my (current) mental model of the situation: - x='`whoami`' - x is set to the literal string `whoami` - echo $x - Parameter expansion: turn into echo `whoami` - Should this be then command substituted into "john"? |
|
|
From https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/utilities/V3_chap02.html#tag_19_06 <<< 2.6 Word Expansions This section describes the various expansions that are performed on words. Not all expansions are performed on every word, as explained in the following sections and elsewhere in this chapter. The expansions that are performed for a given word shall be performed in the following order: 1. Tilde expansion (see 2.6.1 Tilde Expansion), parameter expansion (see 2.6.2 Parameter Expansion), command substitution (see 2.6.3 Command Substitution ), and arithmetic expansion (see 2.6.4 Arithmetic Expansion) shall be performed, beginning to end. See item 5 in 2.3 Token Recognition. 2. Field splitting (see 2.6.5 Field Splitting) shall be performed on the portions of the fields generated by step 1. 3. Pathname expansion (see 2.6.6 Pathname Expansion) shall be performed, unless set -f is in effect. 4. Quote removal (see 2.6.7 Quote Removal), if performed, shall always be performed last. >>> "Following order" here is 1, then 2, then 3, then 4. Within 1 they're *all* done "beginning to end". There's a reference to "token recognition" but nothing that would suggest that those 4 parts in step 1 would be done one after the other with another round of token recognition on the result in-between each (which anyway wouldn't make sense as those could yield tokens that have already been processed in previous steps). |
|
|
Oh, I must have misread it. I guess I interpreted "beginning to end" as referring to doing each one in order, not going linearly through the word. I suppose that _could_ be clarified. Thanks for clarifying! I don't think I have anything to add anymore. |
|
|
Bash in "regular" mode is not conforming, possibly to maintain "bug compatibility" with *broken* scripts. (I was surprised experiment with actual shells show inconsistency before realizing there's a difference in mode of operation). |
|
|
Yeah, I understand that. I tried again, and got "`whoami`". I guess I typod x=`'whoami'` the first time. ksh(1) also prints "`whoami`" I still think that "beginning to end" should be made clearer to prevent this misreading. Maybe write it as e.g. "T.e., p.e., c.s., and a.e. shall be performed, through the beginning of the word to the end of it, but the results of these expansions shall not be further expanded by the same rules in this step.". I admit that this is a matter of whether one thinks that standards should contain only the minimum normative text, or try to be actively helpful to the implementer/casual reader. If the former is the case here, I'd suggest clarifying this in informative text. I admit that I ran into this while referencing the standard to educate myself on the specifics, not reading it fully to implement it. I can understand that someone in the latter position wouldn't have this issue. |
|
|
re:0001955:0007313 XRAT C.2.6 already says this: Step (1) indicates that parameter expansion, command substitution, and arithmetic expansion are all processed simultaneously as they are scanned. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-11-10 18:02 | luna | New Issue | |
| 2025-11-10 18:02 | luna | Status | New => Under Review |
| 2025-11-10 18:02 | luna | Assigned To | => ajosey |
| 2025-11-10 18:42 | luna | Note Added: 0007305 | |
| 2025-11-10 18:51 | calestyo | Note Added: 0007306 | |
| 2025-11-10 18:57 | luna | Note Added: 0007307 | |
| 2025-11-10 20:55 | stephane | Note Added: 0007308 | |
| 2025-11-10 21:16 | luna | Note Added: 0007309 | |
| 2025-11-11 04:38 | dannyniu | Note Added: 0007310 | |
| 2025-11-11 10:52 | geoffclare | Project | 1003.1(2004)/Issue 6 => 1003.1(2024)/Issue8 |
| 2025-11-11 15:34 | luna | Note Added: 0007313 | |
| 2025-11-11 16:19 | oguzismailuysal | Note Added: 0007314 |
