There appears to be a missing check for mismatched [] around an array index reference.

[dshuman52]

For bugs

• Rule Id (if any, e.g. SC1000):
• My shellcheck version (shellcheck --version or "online"):
• ShellCheck - shell script analysis tool
  version: 0.9.0
  license: GNU General Public License, version 3
  website: https://www.shellcheck.net

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

REVISED EXAMPLE (my original had a mismatched {} pair I did not see).

#!/bin/bash
b[1]='2'

a="${b(c]}"

echo "a=${a}"

EXTENDED REVISED example - the order of mismatch [] with () does not change the problem. Even mismatched multiples do not generate an error two [[ and one ). (same result as revised example above)

#!/bin/bash
b[1]='2'

a="${b[[c)}"

echo "a=${a}"

ORIGINAL EXAMPLE

#!/bin/bash
b[1]='2'

a="${b(c])"

Here's what shellcheck currently says: (the online version not my version associated with Geany)

REVISED EXAMPLE the {} bracket pair is complete.

$ shellcheck myscript
No issues detected!

$

ORIGINAL EXAMPLE

$ shellcheck myscript

[Line 4:](javascript:setPosition(4, 4))
a="${b(c])"
^-- SC1009 (info): The mentioned syntax error was in this parameter expansion.
^-- SC1073 (error): Couldn't parse this double quoted string. Fix to allow more checks.

[Line 5:](javascript:setPosition(5, 1))

^-- SC1072 (error): Expected end of double quoted string. Fix any mentioned problems and try again.

$

Here's what I wanted or expected to see:

REVISED EXAMPLE

This appears to be an actual undetected error as the array index reference is not properly enclosed in [] and shellcheck reports no error at all. Should this be submitted as a new issue or it this acceptable?

ORIGINAL EXAMPLE

Clearly in this case the only double quoted string is closed. Clearly also inside this double quoted string there are unpaired [] or () in this case. The only ( should obviously be a [. Admittedly in this case the message is NOT incorrect; however it is also not very helpful in more complicated situations. Question would it be preferable when finding paired double quotes in this case that mismatched pairs of delimiters inside the double quotes would potentially provide a more helpful identification of the issue (maybe two messages one for the mismatched bracket/parens too. I have had some lengthy strings of including multiple variables often with indicies and identification of the mismatched bracket, paren, curly bracket, sq bracket would in my opinion be an improvement. You obviously have more experience in this area and maybe this is not a better idea.

I use Geany to call shellcheck. Geany does a wonderful job of visually flagging mismatched double and single quotes, in most cases. Such that I fix them before invoking shellcheck. Therefore considering that the editor is performing the quote pairing check reasonably in a visual manner. In my limited opinion having shellcheck more concerned with mismatched parens and brackets would be an improvement as the quote problems are often effectively illustrated by Geany. I am NOT advocating that checking of quotes by shellcheck should be eliminated.

I have not figured out how to demo this yet but I got a similar situation generating an SC1078 message about mismatched double quotes that often in my case turn out to be mismatched parens or brackets. As I tend to construct multiple variable strings primarily for use by echo it is not unusual for me to fat finger one or more bracket/parens in the multi variable strings being created. I even used these multi-variable strings to construct validated paths and file names, etc. Knowing that the Double Quote errors even mismatched double quotes could be a problem with parens and brackets helps me now. But when coding late night if mismatched brackets and parens were more actively identified, I believe it could be helpful.

In general considering bash strings delimited by quotes, parens/brackets must be properly nested. It appears all delimited strings must be completely contained in any other delimited string. In this case the (...] inside of { ... } I believe is an error. This occurs before the consideration of the " ... " string considering the { ... } is inside the double quotes. Yes in a case statement outside of a string use of a ')' without the corresponding '(' is valid and would make delimiter checking more difficult. In this case the immediate enclosing delimiters would be case ... esac that exception ends once any code contains any other starting delimiter like " ' ( { [ which reiniates testing for nested delimited strings.

Please consider the appropriate changes based on your better knowledge of any adverse effects the request could create.