Re: Bash-5.2 Release available

[Corey Hickey]

On 2022-10-31 13:04, Corey Hickey wrote:
> On 2022-10-31 08:25, Chet Ramey wrote:
> > On 10/28/22 9:22 PM, Corey Hickey wrote:
> > > On 2022-09-26 12:33, Chet Ramey wrote:
> > > > There are a few incompatible changes between bash-5.1 and bash-5.2. Here-
> > > > documents and here-strings use temporary files if the shell compatibility
> > > > level is 50 or lower. The `unset' builtin in bash-5.2 treats array
> > > > subscripts
> > > > `@' and `*' differently than previous versions, and differently depending on
> > > > whether the array is indexed or associative. Bash-5.2 attempts to prevent
> > > > double-expansion of array subscripts under certain circumstances, especially
> > > > arithmetic evaluation, by acting as if the `assoc_expand_once' shell option
> > > > were set. Set the compatibility level appropriately to revert to previous
> > > > behavior; details are in the file COMPAT.
> > >
> > > I think I encountered the array subscript change, and I'm having some trouble.
> >
> > Thanks for the report. I left the arithmetic evaluation of associative
> > arrays using `@' and `*' as keys alone for backwards compatibility, but
> > it needs to move up with the rest of the compatibility level code. Here's
> > a patch that does that.
>
> Thanks. I tested the patch as applied on top of git a99d905216cc0 and it
> works the way I would expect.
>
> $ ./bash -c 'declare -A assoc ; var=@ ; assoc[$var]=1 ; echo "$((1 + 
> assoc[$var]))"'
> 2

I was experimenting with this and trying to understand the extent of
code execution within arithmetic evaluation, and what are safe ways to
prevent it, based on:

https://unix.stackexchange.com/questions/627474/how-to-use-associative-arrays-safely-inside-arithmetic-expressions

An example from that page is that in bash 5.0, assoc_expand_once does
not suffice to prevent code execution of array keys within arithmetic
expansion. I can reproduce that with bash 5.1.

$ var='x]+b[1$(uname>&2)' ./bash -O assoc_expand_once -c 'typeset -A a; 
((a[$var]++)); typeset -p a'
Linux
declare -A a

Escaping the variable in the array subscript does seem to work to
prevent code execution (with or without assoc_expand_once).

$ var='x]+b[1$(uname>&2)' ./bash -c 'typeset -A a; ((a[\$var]++)); typeset -p a'
declare -A a=(["x]+b[1\$(uname>&2)"]="1" )


In bash 5.2, the default behavior seems to prevent code execution:

$ var='x]+b[1$(uname>&2)' ./bash -c 'typeset -A a; ((a[$var]++)); typeset -p a'
declare -A a=(["x]+b[1\$(uname>&2)"]="1" )

...while the escaped dollar sign gets interpreted as a literal dollar
sign:

$ var='x]+b[1$(uname>&2)' bash -c 'typeset -A a; ((a[\$var]++)); typeset -p a'
declare -A a=(["\$var"]="1" )



Greg, why do you say this part?

> https://mywiki.wooledge.org/BashPitfalls#pf62
>
>    As of bash 5.2, the only safe, working way to modify an element of an
>    associative array in a calculation is to make a temporary copy of the
>    value in a regular (string) variable.

I can see that pre/post 5.2 compatibility would be problematic
without a temporary variable--earlier versions of bash require escaping
the dollar sign and 5.2 does not give that any special meaning.

Other than forward/backward compatibility, is there some other problem
with the 5.2 behavior that I am missing? From what I've seen so far, 5.2
(with Chet's patch) has the least surprising behavior to me (given that
I consider recursive expansion of array keys to be surprising).

-Corey