bash doesn't compile when configured with --disable-bang-history

[Ken Partridge]

Configuration Information [Automatically generated, do not change]:
Machine: arm
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux 192.168.0.201 3.8.13 #1 SMP Thu Sep 12 10:27:06 CEST 2013 ar
Machine Type: arm-unknown-linux-gnu

Bash Version: 5.0
Patch Level: 0
Release Status: release

Description:
  It is not possible to selectively disable the history expansion with
   --disable-bang-history

Repeat-By:
  ./configure --disable-bang-history
  make


Fix:
  In shell.c surround histexp_flag with #if defined (BANG_HISTORY)
   ?

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast Ltd, an innovator in Software as a Service 
(SaaS) for business. Providing a safer and more useful place for your human 
generated data. Specializing in; Security, archiving and compliance. To find 
out more visit the Mimecast website.

Unexpected result of array assignment

[Darren 'Tadgy' Austin]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-LQgi2O/bash-5.0=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-parentheses -Wno-format-security
uname output: Linux phil 5.0.0-13-generic #14-Ubuntu SMP Mon Apr 15 14:59:14 
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.0
Patch Level: 3
Release Status: release

Description:
There seems to be unexpect (a bug?) behaviour with bash's handling of 
array assignments.
Specifically, if you try to assign an array element a value containing 
that same array value, it fails to work.
See example below :)
Bug confirmed by the folks in #bash on Freenode - unable to explain 
what is happening.

Repeat-By:
declare -A foo
foo=(["key"]="value1")
declare -p foo
foo=(["key"]="${foo["key"]} value2")
declare -p foo

The above should result in 'foo["key"]' having a value of 'value1 
value2', but the result is simply ' value2', which I believe to be incorrect 
behaviour.

Re: Unexpected result of array assignment

[L A Walsh]

On 2019/07/17 18:16, Darren 'Tadgy' Austin wrote:
> Repeat-By:
> declare -A foo
> foo=(["key"]="value1")
> declare -p foo
> foo=(["key"]="${foo["key"]} value2")
> declare -p foo
>
> The above should result in 'foo["key"]' having a value of 'value1 
> value2', but the result is simply ' value2', which I believe to be incorrect 
> behaviour.
>   

In bash4.4.12, Using:

I think you need to tell bask that you are updating 'foo'
instead of assigning to it:

This seems to do what you want:

foo+=([key]="${foo[key]} value2")
> my -p foo
declare -A foo=([key]="value1 value2" )

or w/quotes:
foo+=(["key"]="${foo["key"]} value3")

> my -p foo
declare -A foo=([key]="value1 value2 value3" )

I think that without the update it becomes an assign and clears
the value assigned to 'key' before using it to form the string.

It certainly isn't intuitive, but I don't know if there is a
guarantee of it picking up the value of "foo[key]" before initializing
the target space.