Re: Changing the way bash expands associative array subscripts

[Koichi Murase]

2021年4月19日(月) 7:01 Chet Ramey <chet.ramey@case.edu>:
> On 4/16/21 12:11 PM, Koichi Murase wrote:
> >> nobody should be surprised to see a `double expansion'.
> >
> > In that case, I agree that no one would be surprised by the double
> > expansion of the *variable names* because it's the purpose of the
> > namerefs.  But I don't think everyone would necessarily expect the
> > *subscripts* would also be double-expanded.
>
> In this instance, on the rhs of an assignment statement, there's no need to
> treat subscripts any different than any other part of the value string.
> They have no semantic meaning there.
>
> When used `normally', subscripts are expanded when expanding an array
> element value (${a[key]}). I don't see any of this as inconsistent.

Yes.  The current behavior of indirect expansions and namerefs is
consistent, but I just think naive users would be surprised just like
the `unset' case.  But, as you told us, we cannot protect from every
possibility of such people's bad assumptions.

> > Yes, but if `unset' is defaulted to `assoc_expand_once' behavior while
> > indirect expansions and namerefs aren't changed, users still need to
> > do two different ways of quoting: « unset "a[$key]" » versus «
> > iref='a[$key]'; echo "${!iref}" » and « declare -n nref='a[$key]';
> > echo "$nref" ».
>
> I just don't see this as the same problem you do. Assigning a string value
> to a variable is not the same thing as expanding a variable's value.
>
>
> > In my point of view, indirect expansions and name references are also
> > the places where unintended word expansions (including command
> > substitutions) could be caused by naive users.  For example, something
> > like
> >
> > key=$(< untrustworty-file.txt) # can be e.g. key='$(echo injected >&2)'
> > iref=a[$key]
> > echo "${!iref}"
>
> That's just bad code. You can't protect people from everything, and
> sometimes you shouldn't try.

Yes, we can't protect people from everything.  I just thought it's not
consistent that we try to protect people from « unset "a[$key]" » but
not from « iref=a[$key] ».  « unset "a[$key]" » seems equally just bad
code to me, so I would be opposed to defaulting the
`assoc_expand_once' effect on `unset'  to make it "safer" by
sacrificing the consistency for the key=@ case.

> > For the option `assoc_expand_once', I don't know a
> > perfectly consistent solution, but one of possible (incomplete) ways
> > might be treating 'assoc[@]' in many places as the single element
> > reference with `shopt -s assoc_expand_once':
> >
> >    https://lists.gnu.org/archive/html/bug-bash/2021-04/msg00123.html
>
> I already answered this in a separate message. I don't think you need to
> bring `assoc_expand_once' into it to change some of these cases.

Thank you for your answers.

> > Or another solution might be introducing special syntactic treatment
> > of `unset' arguments:
>
> Nope, not going to go that way without much better reasons than I've seen
> so far.

OK.  I've already written what I wanted to say so would like to leave
it to other people.  Maybe konsolebox and other people have some
deeper arguments, but I respect your final decision.

--
Koichi