Re: Question about associative array runtime assignment vs literal initialization

On 12/23/25 11:13 AM, Koichi Murase wrote:
> 2025年12月23日(火) 23:47 Chet Ramey <[email protected]>:
>> On 12/22/25 10:01 AM, Koichi Murase wrote:
>>> I believe « declare -A assoc=("${kv[@]}") » should be supported [where
>>> kv is an indexed array in the form kv=(key1 value1 key2 value2 ...)].
>>
>> https://lists.gnu.org/archive/html/bug-bash/2025-12/msg00030.html
>>
>> explains why this doesn't happen. It seems like you want a different
>> order of operations.
> 
> Could you point me to which specific part of the above reply
> (2025-12/msg00030) explains why that doesn't happen? In my
> understanding, 2025-12/msg00030 explains the reason that
> 
>    «kv=('[key1]=value1'); declare -A assoc=("${kv[@]}")»
> 
> doesn't set «assoc[key1]=value1», but it does not explain the reason that
> 
>    «kv=(key1 value1); declare -A assoc=("${kv[@]}")»
> 
> doesn't set «assoc[key1]=value1».

OK. Let's try another tack here.

I'll skip over the part that explains why the declare command is equivalent
to

declare -A assoc
assoc=("${kv[@]}")

That's this part: "`declare' is a so-called `declaration utility'. ..."

The way compound array assignment works is that the words between the
parens are first tokenized, then the assignment proceeds depending on
what kind of array and what kind of assignment.

That's what this text means:

"When you parse the compound assignment to an associative array assignment,
the shell has to determine whether or not you're using subscripted array
assignment or key-value pair assignment (kvpair). The first word in the
list determines how the assignment treats the list. This happens before
the individual words are expanded, since it determines how you expand
keys, subscripts, and values."

So this is a kv-pair associative array compound assignment statement.
kv-pair assignments are treated so these two statements are equivalent:

assoc=( [key1]=value1 )
assoc=( key1 value1 )

(my guess is that this equivalence is the root of your complaint).

That's what this text means:

"In this case, the word is

$(
     echo [A]=a
     echo '[B]=b'
     echo ['C']=c
   )

which is not a subscripted assignment, so it's treated as the key in a
kvpair. There's no value, so the value is "". "

In your example, the word is "${kv[@]}" and the value is "". So we
have the equivalent of

assoc=( ["${kv[@]}"]="" )

> As in 2025-12/msg00030, the current behavior of the first case with
> «kv=('[key1]=value')» is explained by the ordering of the operations;
> subscripted arguments are first identified, and then the shell
> expansions are performed, and I do agree with the current ordering of
> the operations.

The two examples do it the same way.

> However, I don't see how some ordering of operations can explain the
> current behavior for the second case with «kv=(key1 value1)». The
> behavior of the second case seems to be simply caused by missing word
> splitting, but not by the ordering of word splitting, as far as I
> understand.

You want word splitting to happen before the keys and values are
identified, not during any individual assignment statements that
might result. 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.

You want key-value pair assignment to differ from subscripted assignment
in a way that makes them explicitly incompatible:

> * 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.

Yes, you want

kv=( key1 value1 )

assoc=( xyz "${kv[@]}" aaa bbb )

to result in

[xyz]=key1 [value1]=aaa [bbb]=""

Caveat user, I suppose, but I don't see how this helps much.

-- 
``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/

-----BEGIN PGP SIGNATURE-----

wmMEABEIACMWIQR8ATX7CIqvbGbGULm7WGnwZOp0qwUCaVV1WAUDAAAAAAAKCRC7WGnwZOp0q8nP
AJ9PuAzgY+U6hXg3UngcSPndgbPHNwCeIgkbHK2/sdYhO0gdHc+QrchLLTg=
=6sPk
-----END PGP SIGNATURE-----