False positive for 1072 when there's inline disable directives

[mechalynx]

For bugs

• Rule Id: 1072
• Version: local 0.4.6 / also occurs online
• I tried on 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

if [[ "$1" =~ [0-9]+ ]]
then
  echo "$1"
# shellcheck disable=1001
elif [[ "$1" =~ [^0-9] ]]
then
  echo "$2"
fi

Here's what shellcheck currently says:

Line 3:
if [[ "$1" =~ [0-9]+ ]]
^-- SC1009: The mentioned parser error was in this if expression.
 
Line 4:
then
^-- SC1073: Couldn't parse this then clause.
 
Line 7:
elif [[ "$1" =~ [^0-9] ]]
     ^-- SC1072: Unexpected keyword/token. Fix any mentioned problems and try again.

Here's what I wanted or expected to see:

No error exists in that code. The false positive does not occur if the disable directive is missing or at the block level (outside the if or a function block).

[Nightfirecat]

It's because the disable directive is in the wrong place. (source)

The following raises no errors:

#! /usr/bin/env bash

# shellcheck disable=1001
if [[ "$1" =~ [0-9]+ ]]
then
  echo "$1"
elif [[ "$1" =~ [^0-9] ]]
then
  echo "$2"
fi

[mechalynx]

@Nightfirecat That's my point. It should be treated as referring to the line immediately following it or, if it's not supposed to ever be used there, throw an error indicating that. Instead it falsely reports a different error.

[koalaman]

I agree, you should at least be getting a warning. Scoping directives to statements wasn't as clever as I thought it would be

[mechalynx]

@koalaman I assume this might not be that easy to fix. Do you mind if I add a note to the relevant page on the wiki (the one Nightfirecat linked to) that mentions this bug and recommends avoiding directives within if clauses? I would have done so already but not sure if it's desirable on your part.

Just so people have an obvious place to look for an answer until this can be resolved.

edit - It seems it consistently throws 1072 no matter where the directive is placed within the then clause. If adding info on the Directive page is ok, perhaps it's a good idea to add it to the wiki page for 1072 as well, since that's likely the place people will be looking for an answer at.

[koalaman]

Feel free to update the wiki. I suspect it's actually relatively easy to fix (in the sense of adding a warning), but I'll have to look more into that when I get a chance.

[mechalynx]

Wiki updated on the Directive, SC1072 and Parser Error pages. I hopefully made the note clear but discreet. I'll try to keep an eye out to revert the changes when you get around to fixing this.

Thanks!

[koalaman]

Now you should at least get an explicit warning rather than a weird parsing failure, both for elif/else/fi/done and for branches in statements.

[mechalynx]

@koalaman I'll modify the wiki to mention that this bug will be fixed in the next version and is already fixed on shellcheck.net, until the next release. Thanks!

[LucasLarson]

I’m still able to regenerate this error on shellcheck.net with only the following code

#!/bin/sh
[ ! ]