Another trigger for SC2295?

[jaimet]

For bugs

• Rule Id (if any, e.g. SC1000): SC2295
• My shellcheck version (shellcheck --version or 'online'): online
• [x] I tried on shellcheck.net and verified that this is still a problem on the latest commit
• [ ] It's not reproducible on shellcheck.net, but I think that's because it's an OS, configuration or encoding issue

For new checks and feature suggestions

• [x] shellcheck.net (i.e. the latest commit) currently gives no useful warnings about this
• [ ] I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

Here's a snippet or screenshot that shows the problem:

#!/bin/bash
my_string='3'
substring='[123]'

if [ "${my_string/$substring/hello}" = "$my_string" ] ; then
  echo "${substring} is not in ${my_string}"
else
  echo "${substring} was found in ${my_string}"
fi

if [ "${my_string/$substring}" = "$my_string" ] ; then
  echo "${substring} is not in ${my_string}"
else
  echo "${substring} was found in ${my_string}"
fi

FWIW, the above script prints:

[123] was found in 3
[123] was found in 3

i.e. I think that what is happening here is exactly what is described in the rationale for SC2295 i.e. [123] is being treated as a (posix) bracket expression.

Here's what shellcheck currently says:

$ shellcheck myscript
No issues detected!

Here's what I wanted or expected to see:

I think (but I am not sure) that this should trigger SC2295 twice.

(I got the idea for this from here - it reminded me of this, which explicitly refers to SC2295.)

(PS Thank you for ShellCheck - this tool has taught me more about the shell than any other resource!)