2026年1月1日(木) 4:11 Chet Ramey <[email protected]>:
> On 12/23/25 11:13 AM, Koichi Murase wrote:
> > 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.
Yes, for the non-subscripted form of the words. I now understand that
the assumption in the original explanation has been that the
identification of keys and values for «assoc=(key1 value1)» is
performed at the lexical level. 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).
> 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.
I agree that the word splitting doesn't take effect for the
subscripted form of the words. I'm talking about word splitting for
the non-subscripted form (which doesn't have an assignment form),
which can be different from word splitting of the subscripted form.
> You want key-value pair assignment to differ from subscripted assignment
> in a way that makes them explicitly incompatible:
What kind of incompatibility does this mean specifically? They are
different by definition, and I don't think they need to be compatible
with each other, just as the treatment of word splitting between
«v="${a[@]}"» and «echo "${a[@]}"» is different.
At least, for indexed arrays, the effect of word splitting for
«indexed=([0]="${a[@]}")» and «indexed=("${a[@]}")» is different. In
the subscripted form, the right-hand side «"${a[@]}"» wouldn't
actually be split, while «"${a[@]}"» in the non-subscripted form is
split and results in multiple words. I don't think it is strange to
request that word splitting of the arguments for associative arrays be
similar to that for indexed arrays.
> > * 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]=""
Yes. Even though the suggested example doesn't seem to make much
sense, that's the most natural behavior, given we support
«assoc=("${kv[@]}")» as suggested in the original feature request [1].
I don't think this specific case justifies the "strange" behavior (in
users' perspective) that «assoc=("${kv[@]}")» results in
«assoc["${kv[@]}"]=""».
[1] https://lists.gnu.org/archive/html/bug-bash/2019-07/msg00056.html
----
To be more precise, I assume the behavior of the following
pseudo-code, which is also more consistent with mixed forms of
compound list for indexed arrays [Note: this is just a pseudo-code to
explain the behavior, but I'm not requesting to adopt this exact
implementation]:
key = NULL;
while ((w = next_word_in_compound_list())) {
if (w->is_subscripted)) {
if (key) { assoc_assign(assoc, key, ""); key = NULL; }
assoc_assign(assoc, expand_to_scalar(w->key), expand_to_scalar(w->value));
} else {
for v in expand_to_array(w->value) {
if (key) { assoc_assign(assoc, key, v); key = NULL; } else { key = v; }
}
}
}
if (key) assoc_assign(assoc, key, "");
--
Koichi
