Re: [PATCH (not final)] (take three?) unset "array[$anything]"

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Wed, Jun 2, 2021 at 11:05 PM Stephane Chazelas <stephane@xxxxxxxxxxxx> wrote:
>
> 2021-06-02 19:04:01 -0700, Bart Schaefer:
> > On Wed, Jun 2, 2021 at 8:59 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> > What I realized is that for any unset of an array element, the closing
> > bracket must always be the last character of the argument.
>
> D'oh, I had assumed that had been like that in the beginning

No ... it used to do skipparens() which would always stop too soon if
there was an embedded ']', and I changed it to parse_subscript() to
make '\]' possible.

> I think I'd be in favour of breaking these workarounds on the
> ground that it would fix far more existing script (that just do
> unset "hash[$key]") than it would [break].

See my follow-up message comparing variations.

> There's also the question of what to do with

... a bunch of things that aren't documented to work with associative
array elements but accidentally do ...

> My suggestion of making unset a keyword so that unset hash[$key]
> works as expected  while unset "hash[$key]" works as before
> won't fly as we can't possibly make all builtins that take
> lvalues keywords.

Strictly speaking they don't take lvalues, they take shell parameter
names and use them as lvalues.

> We can't really expect people to carry on doing:
>
> () { set -o localoptions +o multibyte -o extendedglob
> unset "hash[${key//(#m)[][\\()\`]/\\$MATCH}]"; }

There's already an unreleased change for the (*) parameter flag to
locally enable extendedglob:

  unset "hash[${(*)key//(#m)[][\\()\`]/\\$MATCH}]"; }

but still unreasonable.