[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: Chet Ramey
Subject: Re: Changing the way bash expands associative array subscripts
Date: Tue, 13 Apr 2021 11:24:06 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1

On 4/13/21 5:01 AM, Koichi Murase wrote:
2021年4月13日(火) 0:16 Chet Ramey <chet.ramey@case.edu>:
On 4/6/21 12:46 PM, Koichi Murase wrote:
Looking at another thread
I'm now also interested in how we can handle the indirect expansions
for 'a[@]' and the namerefs for 'a[@]':

$ declare -A a=(['@']=x [1]=y)
$ # indirect expansions
$ iref1=a[@]; printf '<%s>' "${!iref1}"; echo
$ key=@; iref2=a[$key]; printf '<%s>' "${!iref2}"; echo
<y><x>    # <-- unexpected

But these cases are identical. After the assignment statement, iref2 has
value 'a[@]', just like iref1. I don't see why one would be more unexpected
than the other, and they're both equivalent to ${a[@]}. Unless that's your

That's my point. Sorry for my insufficient explanation. I know why
these examples don't work in the *current* Bash. I also think it
wouldn't work with a naive design of *new* assoc_expand_once either.
But I expected some design consideration enabling a[$key] for an
arbitrary key in the indirect expansions and namerefs.

Why? Why should the shell carry around (and expect the user to remember)
information about the original value assigned to a variable pre-expansion?
And to let that value affect future expansions? That is not a simplifying

What string should we assign to `iref' to
create a reference to the element associated with key=@ with Greg's

Ah, ok. I see. You can assign '\@' to iref to get the behavior you want.
It's not perfect, but it's possible:

Sorry, I'm a bit confused. May I confirm that we are talking about the
behavior after the planned change on the subscript expansions? If you
are talking about the solution with the current Bash, I know that. If
you are talking about the new behavior as I expect, why would
«iref='a[\@]'» work?

Why would it not? The rationale for the change is to eliminate the double
expansion of array indices that happens under certain circumstances, not
eliminate expansion of array indices entirely. If that makes the semantics
more regular and easier to explain, that's a benefit.

(a) Is it because indirect expansions and name references are not
planned to be modified this time (unlike `unset') and will still
require careful quoting of the key strings after the change?

Do you think that array indices should not be expanded at all? Under what
circumstances should they not be expanded? Because the indirect expansions
of array subscripts still undergo a single set of word expansions.

(b) Or, is it because the associative array subscripts will still be
subject to quote removal after the change even though the command
substitutions in the subscripts will not be evaluated (as shown in
your initial example «unset -v a["$key"]» in
https://lists.gnu.org/archive/html/bug-bash/2021-03/msg00056.html )?

These examples are not the same. In each case, the array subscript would
undergo a single round of word expansion. In the `unset' case, the
expansion would happen as part of the standard word expansions performed
before a builtin is invoked, so there would have to be a way to both find
the end of the subscript and avoid expanding it again. In the indirect
expansion case, the subscript is '\@', and after expansion it is `@'.

I thought the purpose of the planned change of the associative array
subscripts is to solve the inconsistency between the usages of ((
a[\$key] )), unset 'a[$key]', etc. and the usages of a[$key]=xxx,
${a[$key]} so that we can write (( a[$key] )), unset "a[$key]",
iref=a[$key], declare -n nref=a[$key], etc.

The purpose of the change is as I wrote above, and as I wrote originally:

"basically force the equivalent of `assoc_expand_once' on all the
time, with additional changes to prevent unwanted double expansion in an
arithmetic expression context."

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

reply via email to

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