[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] devel: fix segfault by unset 'assoc[${x[0]}]'

From: Chet Ramey
Subject: Re: [PATCH] devel: fix segfault by unset 'assoc[${x[0]}]'
Date: Fri, 8 Oct 2021 09:23:46 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.1.2

On 10/6/21 10:47 PM, Koichi Murase wrote:
I'd like the default behavior to be closer to what it is when
assoc_expand_once is enabled, as I said back in March. I think it's
going to be better for users in the long run.

Does that mean the behavior with `assoc_expand_once' being disabled
also modified in a way incompatible with older Bash versions?  I have
been thinking that `shopt -s assoc_expand_once' would be the default
in the future keeping the behavior of `shopt -u assoc_expand_once'.

My original vision was to modify behavior so that, at least for features
like arithmetic expansion and the `[[' command, it would not be needed at
all, and the behavior that users expect naturally would be the default.
Shell builtins are a different issue, since their arguments already undergo
the standard set of word expansions. I had hoped to be able to modify the
default behavior without too much incompatibility.

If the behavior of `shopt -u assoc_expand_once' would also be
modified, I would like to request another switch for the
backward-compatible behavior, in particular, a specific shopt switch
(but not a setting something like `BASH_COMPAT=51' which would involve
other behavior changes). Anyway, we need to maintain the code of the
backward-compatible behavior.

So far, I think I've kept things mostly compatible.

I see.  In order to make such architectural changes, I feel we first
need to determine how the behavior should be changed.  I guess such a
discussion would be again as long as the one in March.  Maybe this
would become just a repetition of the discussion in March, but to

* I still feel that the cleanest solution is to introduce a special
   the syntax-level rule for `unset arr[...]' where the part `arr[...]'
   is treated as if the right-hand side of a variable assignment (just
   like in other assignment builtins such as `declare', `local',
   `export', etc.), i.e., pathname expansions and word splitting is not
   performed on the arguments of the form `name[xxx]'.

I'm not there yet with this one. I feel like the existing quoting can do
the job. The difference between this and a variable assignment is that
variable assignments already have defined behavior. This would be a new

   This might be also useful to distinguish the all-element unset «
   unset a[@] » from the unset of the element of key='@' « unset a['@']

There are some changes along these lines in the devel branch already.

* I would like to request a backward-compatible mode where the extra
   expansions of array subscripts are performed the same as the older
   versions of Bash.  I would like to see a specific option for this
   mode rather than `BASH_COMPAT=51' which would involve other
   behavioral changes.

It's those backward-compatible behaviors that are the problem. Expanding
the subscript multiple times, no matter what the intention was initially,
is the source of most of the issues we're trying to address.

* I feel we need to care about the consistency with the extra
   expansions performed in other contexts:

   - printf -v 'a[$key]'
   - read 'a[$key]'
   - declare 'a[$key]=1'
   - vref='a[$key]'; echo "${!vref}"
   - declare -n nref='a[$key]'

I'm working through these. I think there's a decent framework for them in
the devel branch right now, but I haven't made any substantial changes in

   - etc.

a better architectural solution.

This will not change the observable behavior, but if I would refactor
it, I'd make `valid_array_referecen' return the extracted subscript
and let `unbind_array_element' just receive the extracted subscript
rather than make `unbind_array_element' again extract the subscript.

Thanks, I'll look at this.


``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/

reply via email to

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