[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 14:55:35 +0900 |
2021年3月30日(火) 0:03 Chet Ramey <chet.ramey@case.edu>:
> On 3/15/21 9:41 PM, Koichi Murase wrote:
> > Can you also take care of the behavior of `unset -v 'a[@]''?
>
> Well, you have to pick one behavior or another. The `@' subscript always
> expands to all members of the array. The current behavior is consistent
> with that, and documented.
When `shopt -s assoc_expand_once' is enabled, I think it is better
that `unset -v 'a[@]'' will remove just an element associated with the
key `@' but not remove the entire associative array `a' although it
might be inconsistent to the other places such as `${a[@]}'. More
specifically, I'm thinking of the use case that a user wants to remove
an entry for an arbitrary $key using
unset -v "assoc[$key]"
If `unset -v 'a[@]'' would continue to remove the entire array even
after the change of this time, when key=@, the above command will
cause unexpected behavior for the user: The entire associative array
will be removed. This can be another serious pitfall of Bash
associative arrays which users would easily miss. If this pitfall
would remain, I think the current behavior is better.
But, maybe we can introduce a special syntactic treatment of `unset'
as done for `declare/typeset/local/export/readonly'. Just as ${a[@]}
and ${a[$key]} are treated differently, maybe we can treat
unset -v a[@]
and
unset -v a[$key]
differently. Also, the syntax can recognize `name[key]' as a special
pattern not to be confused with a glob pattern, which is another
typical pitfall of `unset' array elements. Now I think this type of
fix is the cleanest way. The treatment of `test -v a[@]' and `test -v
a[$key]' may also be changed the same as `unset'. Although `test' and
`[' are defined in POSIX, the option `-v' is a Bash extension so the
syntactic treatment might be changed.
> > Maybe this is unrelated to the extra expansions of array subscripts,
> > but is there any reason that Bash disallows empty associative keys?
>
> That's a separate change I haven't considered as part of this.
Yes. If there isn't a strong reason for disallowing the empty
associative-array keys, may I create a new thread of bug-bash for the
feature request of supporting empty keys?
--
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 <=
- 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, 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, 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