Bash interpreting special character within single quotes

Question

Ran into some unexpected but interesting behavior. I was doing a somewhat complex execution when I ran into a situation that from my understanding of how Bash handles characters shouldn't have happened.

Smaller example of issue:

$ arr=( "$(echo '1 && !/==/')" )
-bash: !/=: event not found

What is going on here? To my understanding, the single quotes should force Bash to interpret all the characters literally without doing any type of expansion.

Using Bash 4.1.2.

EDIT: Simplified question for reproduction.

Answer 1

bash exits with an error about a bad event

You have been bitten by the dreaded history substitution (the ! character inside your double quotes). You can disable it with set +H. That won't happen in a script BTW.

About word splitting: you can use readarray (or its alias mapfile)

readarray -t array < <(df -Ph ...)

Answer 2

Smaller example (but probably not smallest), in Bash 4.1:

$ set -H
$ arr=( "$(echo '1 && !/==/' )" )
bash4.1: !/==/': event not found
$ arr=(  $(echo '1 && !/==/' )  )              # no error
$ 

and in Bash 4.4:

$ set -H
$ arr=( "$(echo '1 && !/==/' )" )              # no error
$ arr=(  $(echo '1 && !/==/' )  )              # no error
$ 

That's history expansion allright. It happens quite early in the command line processing, and doesn't parse the whole command before that:

History expansion is performed immediately after a complete line is read, before the shell breaks it into words, and is performed on each line individually.

No idea why it works like that, why the double quoting makes a difference, but it's not the only bug with history expansion I remember hearing about.

You can turn history expansion off with set +H, or set +o histexpand, and it's not enabled in scripts by default anyway.

Also note that Bash 4.1 is more than 10 years old now, even Bash 4.4 (the last with a 4.x version number) was released in 2016. Other bugs have been fixed since 4.1, too, as well as useful features added.