[Top][All Lists]

[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[@]


  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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]