On Fri, Jan 02, 2026 at 17:24:46 -0500, Chet Ramey wrote:
> On 12/31/25 6:58 PM, Koichi Murase wrote:
> > 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?
We're talking about this, right?
assoc=( "${kv[@]}" )
Currently, the behavior makes no sense at all (from a script writer's
point of view), so I have a hard time believing anyone's using it
intentionally.
hobbit:~$ bash-5.3
hobbit:~$ declare -A assoc
hobbit:~$ kv=( '[foo]=bar' '[baz]=quux' )
hobbit:~$ assoc=( "${kv[@]}" )
hobbit:~$ declare -p assoc
declare -A assoc=(["[foo]=bar [baz]=quux"]="" )
Whether the user intended to produce an array with keys 'foo' and 'baz'
or an array with the single key '[foo]=bar' the point is neither of
these things happens.
I doubt anyone writing this in a script *wants* it to produce an array
with the single key '[foo]=bar [baz]=quux' with an empty value. If
someone wants that, they would write "${kv[*]}" instead of "${kv[@]}".
Therefore, my preference would be to declare the current behavior a
bug and replace it with a new behavior, without offering any backward
compatibility option. (If anyone says they're actually using the current
behavior, I will apologize, and you may ignore my preference.)
What that new behavior should be is still a little murky to me, however.
Some script writers may expect assoc=("${kv[@]}") to produce an array
where the first element of kv is a key, the second element is that key's
value, the third element is another key, the fourth element is its value,
and so on. If there are an odd number of elements, then the final key
has an empty value.
On the other hand, some script writers may expect bash to scan the
first element of the list to see whether it matches the form [x]=y
and if so, parse it as a key/value pair. In that case, they may also
expect every element to be scanned that way, or they may expect the
first element's format to indicate the type of parsing that's used for
all elements.
I don't have a good idea for how to reconcile those two (or three)
expectations. Perhaps Koichi Murase does.
I keep thinking of how "array set" works in Tcl. This is a command
that loads keys and values into an associative array. The syntax is:
array set arrayName list
where the "list" argument must have an even number of elements, these
being alternating keys and values.
Maybe a new command like this would be the cleanest way forward. A
bash equivalent might look something like:
loadarray assoc "${kv[@]}"
Maybe add an option that'll clear any existing elements.
If that's too much work, or doesn't fit your vision, feel free to
ignore it. It's just one idea, and I'm not married to it.
