Re: Question about associative array runtime assignment vs literal initialization

2025年12月24日(水) 0:11 Chet Ramey <[email protected]>:
> On 12/22/25 11:15 AM, Koichi Murase wrote:
> > 2025年12月23日(火) 1:05 Koichi Murase <[email protected]>:
> >>> hobbit:~$ declare -A aa="("${kv[@]}")"; declare -p aa
> >>> declare -A aa=([3]="" [a]="half" [two]="and" [2.5]="three" [one]="1" )
> >>
> >> [...] In
> >> this example, ${kv[@]} is outside the double quoting (because the
> >> first double quotation is « "(" » and the second double quotation is «
> >> ")" »), and then the bare ${kv[@]} is subject to word splitting
> >
> > I'm sorry. Actually, my explanation above is wrong, because the
> > right-hand side of the assignment for the declare builtin is not a
> > context where word splitting.happens. The word splitting happens
> > because the declare builtin receives the literal '(one 1 two 2 two and
> > a half 2.5 three 3)' and parses it again. Anyway, the current behavior
> > for the latter example is expected in my understanding.
>
> "You can defer the expansion and let the declare builtin do it by adding a
> layer of quoting. If you quote the rhs of the assignment statement, you
> prevent it from being recognized as a compound assignment by the parser,
> and it undergoes the `normal' string word expansions before the `declare'
> builtin sees it.
>
> For backwards compatiblity, declare accepts compound assignment statements
> as arguments and treats them like standalone compound assignments. This
> isn't how I would choose to do it today, but I did initially, and still
> support it."

These are the explanations for the behavior of the latter example in
[1], «declare -A aa="("${kv[@]}")"». I agree with you about this
behavior, so we don't have to discuss this. What I try to argue is the
behavior for the former example in [1], «declare -A aa=("${kv[@]}")»,
which isn't covered by the above quote "You can defer ... support it".

[1] https://lists.gnu.org/archive/html/bug-bash/2025-12/msg00095.html

--
Koichi