2021年4月19日(月) 7:01 Chet Ramey <chet.ra...@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