2021年4月9日(金) 5:08 Greg Wooledge <g...@wooledge.org>: > On Thu, Apr 08, 2021 at 03:37:33PM -0400, Chet Ramey wrote: > > On 4/6/21 1:42 PM, Greg Wooledge wrote: > > > That said, the fact that you can put 'a[@]' in an indirect variable and > > > get an array expansion out of "${!x}" is completely repulsive to me. > > > > What do you think should happen? > > [...] > > So now I'm not advocating for any change to it. It would break too > many scripts. I can only advise people to start using declare -n > instead, with additional warnings about variable name scoping and > collisions (which are also problems with the indirection hack, or with > eval-based hacks).
I currently don't have any better idea, but in that way, it seems to me that there is no way to represent a reference to an element associated with key=@ under the new `assoc_expand_once', which was what I wanted to argue in my previous reply. Namerefs (declare -n) have the same issue. -- Koichi 2021年4月9日(金) 5:08 Greg Wooledge <g...@wooledge.org>: > > On Thu, Apr 08, 2021 at 03:37:33PM -0400, Chet Ramey wrote: > > On 4/6/21 1:42 PM, Greg Wooledge wrote: > > > That said, the fact that you can put 'a[@]' in an indirect variable and > > > get an array expansion out of "${!x}" is completely repulsive to me. > > > > What do you think should happen? > > What I would have expected originally: an error message and a non-zero > exit status. > > But apparently someone stumbled upon this trick, and passed it around, > and now there's a whole subculture of people who use this as a hack for > trying to pass array variables to functions by reference. (This hack > predates declare -n.) > > So now I'm not advocating for any change to it. It would break too > many scripts. I can only advise people to start using declare -n > instead, with additional warnings about variable name scoping and > collisions (which are also problems with the indirection hack, or with > eval-based hacks). >