Re: Changing the way bash expands associative array subscripts

[Chet Ramey]

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
> > > https://lists.gnu.org/archive/html/bug-bash/2021-04/threads.html#00051,
> > > 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
> > > <y><x>
> > > $ 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
> > point?
>
> 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
change.


> > > What string should we assign to `iref' to
> > > create a reference to the element associated with key=@ with Greg's
> > > suggestion?
> >
> > 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/