[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changing the way bash expands associative array subscripts
From: |
Koichi Murase |
Subject: |
Re: Changing the way bash expands associative array subscripts |
Date: |
Tue, 6 Apr 2021 23:28:13 +0900 |
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
- Re: Changing the way bash expands associative array subscripts, Chet Ramey, 2021/04/05
- Re: Changing the way bash expands associative array subscripts, Koichi Murase, 2021/04/06
- Re: Changing the way bash expands associative array subscripts, Greg Wooledge, 2021/04/06
- Re: Changing the way bash expands associative array subscripts,
Koichi Murase <=
- Re: Changing the way bash expands associative array subscripts, Greg Wooledge, 2021/04/06
- Re: Changing the way bash expands associative array subscripts, Ilkka Virta, 2021/04/06
- Re: Changing the way bash expands associative array subscripts, Greg Wooledge, 2021/04/06
- Re: Changing the way bash expands associative array subscripts, Ilkka Virta, 2021/04/06
- Re: Changing the way bash expands associative array subscripts, konsolebox, 2021/04/06
- Re: Changing the way bash expands associative array subscripts, Greg Wooledge, 2021/04/06
- Re: Changing the way bash expands associative array subscripts, Dennis Williamson, 2021/04/06
- Re: Changing the way bash expands associative array subscripts, Greg Wooledge, 2021/04/06
- Re: Changing the way bash expands associative array subscripts, konsolebox, 2021/04/06
- Re: Changing the way bash expands associative array subscripts, Koichi Murase, 2021/04/06