[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changing the way bash expands associative array subscripts
From: |
Chet Ramey |
Subject: |
Re: Changing the way bash expands associative array subscripts |
Date: |
Thu, 8 Apr 2021 14:33:45 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 |
On 4/6/21 1:55 AM, Koichi Murase wrote:
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[@]}'.
Why with `assoc_expand_once'? Would it not be just as surprising, or more,
to have a `@' remove the entire array if it were the target of the much-
hated `double expansion'? That's part of what we're talking about fixing.
We're having this discussion in the context of assoc_expand_once, or its
effects, being enabled all the time. I agree that those changes are not
needed to have `@' not remove the entire array, but I'm still planning to
move forward with the changes we started out discussing.
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]"
I agree, that's what we're talking about here. But you don't need this:
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.
to achieve that.
I'm not going to make unset a reserved word. It's not necessary.
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?
Sure, let's discuss it.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
- Re: Changing the way bash expands associative array subscripts, (continued)
- Re: Changing the way bash expands associative array subscripts, Chet Ramey, 2021/04/12
- Re: Changing the way bash expands associative array subscripts, Chet Ramey, 2021/04/08
- Re: Changing the way bash expands associative array subscripts, L A Walsh, 2021/04/13
- Re: Changing the way bash expands associative array subscripts, konsolebox, 2021/04/13
- Re: Changing the way bash expands associative array subscripts, Chet Ramey, 2021/04/13
- Re: Changing the way bash expands associative array subscripts, Chet Ramey, 2021/04/08
- Re: Changing the way bash expands associative array subscripts, konsolebox, 2021/04/06
- Re: Changing the way bash expands associative array subscripts, Chet Ramey, 2021/04/08
- Re: Changing the way bash expands associative array subscripts, konsolebox, 2021/04/08
- Re: Changing the way bash expands associative array subscripts, Chet Ramey, 2021/04/08
Re: Changing the way bash expands associative array subscripts,
Chet Ramey <=