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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
