[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changing the way bash expands associative array subscripts

From: Koichi Murase
Subject: Re: Changing the way bash expands associative array subscripts
Date: Tue, 16 Mar 2021 09:41:42 +0800

2021年3月16日(火) 8:12 Chet Ramey <chet.ramey@case.edu>:
> key='x],b[$(echo uname >&2)'
> (( assoc[$key]++ ))
> [...]
> declare -A assoc=(["x],b[\$(echo uname >&2)"]="1" )

I agree with this change. I think the same rule should apply also to
the indexed arrays in the arithmetic command. With `index='0],b[1';
((array[$index]++))', I expect a syntax error rather than an
unexpected structure of the arithmetic evaluation.

> The issue lies with shell builtins. Builtin commands have to undergo the
> full set of shell expansions [...]

Can you also take care of the behavior of `unset -v 'a[@]''?
Currently, even with `shopt -s assoc_expand_once', `unset -v 'a[@]''
clears the entire array, which means that one cannot reliably do
`unset -v "a[$key]"' when `key' contains some user-supplied names.
- I think we should not treat `a[@]' or `a[*]' as "all elements" but
should treat it as an element associated with the key `@' or `*' when
`shopt -s assoc_expand_once' is set and `a' is an associative array.
- The similar cases for indexed arrays are not ambiguous because a
single character `@' or `*' is not a valid arithmetic expression, but
I still think we can also think of changing the behavior of the
indexed arrays as well for consistency.

I haven't thoroughly considered it, but I think the same discussion
applies also to `test -v 'a[@]'', `[[ -v a[@] ]]', etc. where the
shell-expansion step and the array-dereference step is separated.

> What do folks think?

Maybe this is unrelated to the extra expansions of array subscripts,
but is there any reason that Bash disallows empty associative keys?
This is also a point that confuses users related to the keys of
associative arrays. Associative arrays in other languages usually
accept an empty key. I usually use `a[x$key]' for the workaround, but
I personally feel we should support empty associative keys in Bash. I
also remember that at least two other people were confused by the
current behavior not accepting the empty key.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]