Re: Question about associative array runtime assignment vs literal initialization

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

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.

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.

Anyway, regardless of the background for the current implementation, I
believe the behavior of «kv=(key1 value1); declare -A
assoc=("${kv[@]}")» should be fixed to cause «assoc[key1]=value1» (but
not «assoc['key1 value1']=»). In the first place, «declare -A a=(k v)»
and «"${assoc[@]@K}"» were introduced in 5.1 after [1], where the
usage «array=( a 1 b 2 c 3 ); declare -A hash=( ${array[@]} )» was
explicitly mentioned. However, the @K transformation didn't fit the
use case of «array=( a 1 b 2 c 3 ); declare -A hash=( ${array[@]} )»,
so @k was suggested [2] and introduced in 5.2. However, because of the
current behavior of missing the word splitting, the originally
requested usage, which motivated «declare -A a=(k v)» and
«"${assoc[@]@k}"» is still not possible. This issue actually seems to
have already reported in [3].

[1] https://lists.gnu.org/archive/html/bug-bash/2019-07/msg00056.html
[2] https://lists.gnu.org/archive/html/bug-bash/2021-08/msg00101.html
[3] https://lists.gnu.org/archive/html/bug-bash/2024-03/msg00143.html

I'm not asking for an explanation about the current behavior, but I'd
request a change in the behavior. More specifically,

* When the word in the compound list for the associative array is in
the form of a subscripted argument «[xxx]=yyy», xxx and yyy are
identified as a key and a value, respectively. Then, after the
identification, the shell expansions are applied to xxx and yyy
(excluding word splitting, which doesn't happen inside subscripts and
right-hand sides of assignments). This is unchanged from the current
behavior.
* 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.

--
Koichi