Re: namerefs to var[idx]

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Fri, Mar 8, 2024 at 5:23 AM Stephane Chazelas <stephane@xxxxxxxxxxxx> wrote:
>
> $ f() { typeset -nu v=$1; echo $v[1]; }
> $ f 'a[2,3]'
> f: no matches found: bc[1]

Things are pretty tangled here:  paramsubst() calls fetchvalue().  In
${v[1]} the entire reference is handled by fetchvalue().  In $v[1],
the $v is handled by fetchvalue() and then the [1] is handled by
paramsubst().  So it ends up being treated as $a[2,3][1], which
produces the same error.  I can't immediately think of any way to fix
that without breaking something else ... ideally we'd make $a[2,3][1]
work instead, but that's a pretty large change.

In the assignment case ...

> $ f() { typeset -nu v=$1; v[1]=foo; }

... the left side of the assignment is interpreted more like ${v[1]}
than like $v[1], so everything "works."  I guess one must remember
that omitting the braces around subscript expansions has always been a
shortcut rather than "the right way to do it".  The braces are
required for correct handling of namespaces, too.

> $ a=12345
> $ f 'a[2,3]'
> $ echo $a
> 1foo45
>
> In that one could expect the first character of the "23"
> substring to be changed

I say "more like" above because:

% a[2,3][1]=b
zsh: no matches found: a[2,3][1]=b
% typeset 'a[2,3][1]'=c
zsh: not an identifier: a[2,3][1]

So using a nameref that way is rather a back door around the check for
identifiers.

This is an interesting variation:

% f() { typeset -n x='v[2]'; typeset -nu v=$1; x=foo; typeset -p v x }
% f 'a[2,3]'
typeset -un v='afoo2,3]'
typeset -n x='v[2]'

So chaining subscripted namerefs isn't really working, probably
because of something similar to the paramsubst()/fetchvalue() division
of labor just mentioned.