Re: Question about associative array runtime assignment vs literal initialization
Chet Ramey <[email protected]>
| Newsgroups | gmane.comp.shells.bash.bugs |
|---|---|
| Organization | ITS, Case Western Reserve University |
| Message-ID | <[email protected]> |
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)» is
> performed 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
(application/pgp-signature, 203 B)
-----BEGIN PGP SIGNATURE----- wmMEABEIACMWIQR8ATX7CIqvbGbGULm7WGnwZOp0qwUCaVhFrwUDAAAAAAAKCRC7WGnwZOp0q45C AKCZmCvZvcmw7x+3WFigS8FNIBwv1QCgj9MD6tUwiMvjgao/+zazkhPP3zA= =z/pu -----END PGP SIGNATURE-----