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
summarize,
* 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
change.
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
behavior.
- 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.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
