Confusing "Expected 'fi'" when incorrect command substitution is used

[memotype]

For bugs

• Rule Id (if any, e.g. SC1000): SC1047, SC1072
• 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 shellcheck.net and verified that this is still a problem on the latest commit

For new checks and feature suggestions

• 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

Not sure if this requires a new check, or fixing the existing checks.

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

(A bit of background in case the code is a bit confusing. This is in a build script that builds Open vSwitch RPMs, but since they take a while to build, and rarely change, the script checks an internal file server to see if the RPMs for the right version already exist, and wget's them if they do)

#!/bin/bash
wget "http://${FILESERV}/ovs-rpms.txt"
if grep -q "openvswitch-${OVS_VERSION}-.*\.rpm" ovs-rpms.txt; then
  while read rpm; do
    wget -N "http://${FILESERV}/$rpm"
    touch "$(basename $rpm)"
  done <(cat ovs-rpms.txt)
  echo 0
fi

Correct code is:

#!/bin/bash
wget "http://${FILESERV}/ovs-rpms.txt"
if grep -q "openvswitch-${OVS_VERSION}-.*\.rpm" ovs-rpms.txt; then
  while read rpm; do
    wget -N "http://${FILESERV}/$rpm"
    touch "$(basename $rpm)"
  done < <(cat ovs-rpms.txt)
  echo 0
fi

(Note the additional < character on the "done" line)

Here's what shellcheck currently says:

  done <(cat ovs-rpms.txt)
       ^-- SC1047: Expected 'fi' matching previously mentioned 'if'.
       ^-- SC1072: Expected 'fi'. Fix any mentioned problems and try again.

Here's what I wanted or expected to see:

Here's what bash says:

bash: syntax error near unexpected token `<(cat ovs-rpms.txt)'

Basically, shellcheck knows something is wrong, but misidentifies the issue (or doesn't catch it earlier in the parsing). Took me a while to figure out what was wrong, and had to run a simplified version in the shell to figure it out, then looked up the BashFAQ entry to remember how to do the redirect right.