Re: Changing the way bash expands associative array subscripts

[Koichi Murase]

2021年4月9日(金) 5:08 Greg Wooledge <greg@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 <greg@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).
>