For bugs

• Rule Id (if any, e.g. SC1000): SC2295
• My shellcheck version (shellcheck --version or "online"): online
• The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2086)
• I tried on https://www.shellcheck.net/ and verified that this is still a problem on the latest commit

For new checks and feature suggestions

• https://www.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/sh
foo1="${bar:-'default value'}"
foo2="${bar:-"default value"}"

On the SC2295 wiki page, it is stated that "Expansions inside ${..} need to be quoted separately, otherwise they will match as a pattern." But I'm not sure that is accurate. If we look at the examples foo1 where we single quote a string, then foo1 will actually contain 'default value'. For foo2 I fear it's more subtle, and afraid it also doesn't do what one would expect. I believe in that case, we end do not end up with "default value" but rather the initial opening quote gets closed. to use square brackets as syntactic example, where write foo2=[${bar:-[default value]}] we end up with foo2=[${bar:-]default value[}], e.g. we close the first quote instead of opening a sub-quote (if that makes sense). Which is most possibly not what we would want. I think the result is not so bad, we just end up with foo2=default value e.g. an unquoted string, and I think in shell, this doesn't even matter if it would contain spaces.

For the # ## % %% cases the SC2295 is correct.

P.S. I'm opening this ticket to get clarification, so I can learn what to (if) modify on the wiki page.