Misleading warning about ranges on association array

[cloorc]

For bugs

• SC2102:
• online:
• The rule's wiki page does not already cover this (e.g. https://github.com/koalaman/shellcheck/wiki/SC2102)
• I tried on https://www.shellcheck.net/ and verified that this is still a problem on the latest commit

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

#!/usr/bin/env bash
declare -A helm
read -r -d '' helm[indexes] <<EOF
...
EOF

Here's what shellcheck currently says:

Ranges can only match single chars (mentioned due to duplicates). See SC2102.

Here's what I wanted or expected to see:

`helm[indexes]` is a kind of association array and this expression does not describe a range.

[kurahaupo]

ShellCheck is correct to issue a warning, but I agree that the choice of warning is quite misleading.

What it's really complaining about is that the [indexes] glob contains the same letter multiple times, which is a common error when people think that [word] will optionally a whole word, like ?(word).

There is a common misconception that commands such as read and unset are exempt from the usual handling of command arguments. This is simply not true; they are indeed subject to globbing. The effect is normally hidden from view because the default behaviour is to leave unchanged any glob that does not match any files.

This can affect you in three ways:

1. If the subscripted variable taken as a glob actually matches one or more files, then those filenames will be substituted:

   touch foo0
   foo=( abc def )
   read -r foo[0] <<<xyz
   declare -p ${!foo@}
   

   outputs:

   declare -a foo='([0]="abc" [1]="def")'
declare -- foo0="xyz"

2. If nullglob is active, then additionally, any glob that doesn't match a file will simply be ignored:

   rm -f foo1
   shopt -s nullglob
   foo=( abc def )
   unset foo[1]
   declare -p ${!foo@}
   

   outputs:

   declare -a foo='([0]="abc" [1]="def")'

3. Even if you can be certain that nullglob is off and that there are no matching files, there's still a less obvious effect: it makes your script slower:

   $ time for ((i=0;i<10000;++i)) do unset "x[0]" ; done
   

   real 0m0.179s
user 0m0.120s
sys 0m0.052s

   $ time for ((i=0;i<10000;++i)) do unset x[0] ; done
   

   real 0m0.756s
user 0m0.248s
sys 0m0.492s

[koalaman]

There is now a warning for read similar to the one for unset. Thanks!