Re: Changing the way bash expands associative array subscripts

[Koichi Murase]

2021年4月6日(火) 21:06 Greg Wooledge <greg@wooledge.org>:
> On Tue, Apr 06, 2021 at 02:55:35PM +0900, Koichi Murase wrote:
> > But, maybe we can introduce a special syntactic treatment of `unset'
>
> When I made a comment about the possibility of unset becoming a keyword,
> Chet said he had no plans to do that.
>
> ... here:
> https://lists.gnu.org/archive/html/bug-bash/2021-03/msg00236.html

Thank you for the pointer. I still think changing the syntactic
treatment of the arguments of the `unset' builtin is the cleanest way
to solve the problem of `key=@; unset -v a[$key]'. Maybe we can ask
Chet why this isn't considered. We now see two benefits of changing
the treatment of the arguments of `unset', 1) `unset -v a[$key]' is
not the subject to the pathname expansions and word splitting. 2) we
can distinguish the erasure of the element associated with key=@
`unset -v a[$key]' from the entire array erasure `unset -v a[@]'. (But
maybe there is a technical difficulty in introducing the new
syntaxes.)

To implement this, `unset' doesn't need to be turned into a shell
keyword, but I thought just the treatment of arguments might be
changed. For a similar example, the assignments in the declare
arguments `declare a[$key]=$value' is treated specially although
`declare' is not a shell keyword but a builtin.

In the follow-ups, rle has pointed out that `unset' would be no longer
overridable by functions if it was turned into a keyword. But, if we
just change the treatment of the arguments of the form `name[key]', we
don't have to break the backward compatibility. For the backward
compatibility, we can keep the treatment of the quoted arguments like
'a[$key]' but just change the form `name[key]' which is currently
unsafe against the pathname expansions. There may be some use cases
broken by this change, but they would be something highly unusual like
the following:

$ key='1] b[2'
$ unset -v a[$key]   # intended to remove `a[1]' and `b[2]'

or

$ touch a1 a2 a3
$ unset -v a[1-3]   # intended to remove `a1', `a2', and `a3'

I don't think there are existing codes relying on these behaviors.
Conversely, there are definitely more codes naively writing as `unset
a[1]' which can be broken by pathname expansions. For this reason, I
think we don't have to care about the backward compatibility for this
change, but rather we can expect that the compatibility would be
improved.

--
Koichi