On 12/31/25 6:58 PM, Koichi Murase wrote:
You want word splitting to happen before the keys and values are identified, not during any individual assignment statements that might result.Yes, for the non-subscripted form of the words. I now understand that the assumption in the original explanation has been that the identification of keys and values for «assoc=(key1 value1)» isperformed at the lexical level.
Yes, since the kvpair and subscripted assignments have to be treated slightly differently. The original rationale for kvpair assignments was primarily to avoid the parsing and quoting difficulties involved in finding the end of the subscript (which makes the process much simpler), not to change the assignment semantics, so the differences are minimized.
My request is essentially to defer the identification of keys and values in non-subscripted forms after shell expansions (while keeping the identification between subscripted vs non-subscripted forms of lexical words to be performed before shell expansions).
OK, you want a new feature. Since this is not compatible with previous behavior, and since bash has never behaved this way, how should this new feature be exposed? Should there be a shell option that changes the expansion behavior? Some new assignment syntax? Something else?
The key and value in [key1]=value1 aren't word split at all, so I guess you could say it's `missing'. I don't see this omission of word splitting as `missing' in the same way that I don't view a="${kv[@}" echo one not running a command named `value1' as `missing' word splitting.I agree that the word splitting doesn't take effect for the subscripted form of the words. I'm talking about word splitting for the non-subscripted form (which doesn't have an assignment form), which can be different from word splitting of the subscripted form.
It can be, but is not now. So this is new behavior.
You want key-value pair assignment to differ from subscripted assignment in a way that makes them explicitly incompatible:What kind of incompatibility does this mean specifically? They are different by definition,
No, not really. They are syntatically different, but the kvpair variant is just syntactic sugar for the subscripted variant. You would like them to be different; that is the feature request. We're just discussing how to make that functionality available.
and I don't think they need to be compatible
with each other, just as the treatment of word splitting between
«v="${a[@]}"» and «echo "${a[@]}"» is different.
At least, for indexed arrays, the effect of word splitting for
«indexed=([0]="${a[@]}")» and «indexed=("${a[@]}")» is different.
Yes, because the treatment of indices for the non-subscripted version of the compound assignment is different. You can infer the indices in the latter version, so you can perform word splitting. Since you can't infer the indices with the kvpair form of assignment, it's more consistent with the subscripted form (and safer) not to perform word splitting before tokenizing and constructing the equivalent subscripted assignment.
the subscripted form, the right-hand side «"${a[@]}"» wouldn't
actually be split, while «"${a[@]}"» in the non-subscripted form is
split and results in multiple words. I don't think it is strange to
request that word splitting of the arguments for associative arrays be
similar to that for indexed arrays.
So you would want to perform word expansions, including word splitting, on the entire string between the parens (since an assignment statement is a single word), then use the resulting words as key-value pairs, without performing any additional expansions:
* Otherwise, shell expansions are applied to the word (including word splitting), and keys and values are picked up from generated (i.e. split) words. This is the change in the behavior.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
