Shellcheck doesn't recognize [ as a regular command.

[Artoria2e5]

Although the misuse of && in [ expr ] is common, it's still important to treat [ as a command, and the check for && / || should only happen when the last argument of the last command in the term appears to be ] (technically both quoted and un-quoted; but people that knows quoting also works since it is only an arg doesn't seem likely to make && mistakes.)

The test content is the same as #463.

# [(){ local IFS=' '; echo -n "$*"; } # shellcheck hangs at this funcdef
# bash: disable the [ builtin
enable -d [; echo -e '#!/bin/bash\necho "$@"'>/tmp/[; chmod +x /tmp/[; PATH=/tmp
[ a && echo b # here we also see shellcheck recgonize && like a syntax keyword; another issue.

A quick review on POSIX.1 2013 Volume 3 Shell & Utilities shows that [ is only a special form of the test util, while [[ and ]] may be keywords.

[izabera]

shellcheck can't determine if your script will produce an error because you purposely wrote something that can only be determined at runtime

how about this?

(( RANDOM % 2 )) &&
enable -d [; echo -e '#!/bin/bash\necho "$@"'>/tmp/[; chmod +x /tmp/[; PATH=/tmp
[ a && echo b

do you think shellcheck should emit a warning 50% of the times?

[Artoria2e5]

@izabera

NO. [ is never a special syntax structure. It is only a command.

[koalaman]

Incorrectly treating [ as a special command is a conscious design decision.

This gives much better understanding of intent, like && as you mention, and also ||, > for comparisons, ( for grouping and ( for regex.

Unfortunately it also means that it trips up when people do less common things like overriding [, or when dynamically generating expressions or using variables as operators.

It's really sad when correctness suffers like this, annoying advanced users in order to better catch clueless newbies' mistakes, but I think ShellCheck is more valuable as a tool for doing it.

[kurahaupo]

(update: opened as separate issue #495)
Perhaps this (and similar comments about SC1007) points towards having each warning grouped and graded, so that they can be selected on the command line with keywords rather than numbers.

And being able to put a directive just once in the source to disable particular warnings globally.

Perhaps like these:

    # shellcheck: disable special-[ # applies to next line
    # shellcheck: lines 5 disable special-[ # applies to next 5 lines
    # shellcheck: scope disable assignment # applies to end of current compound command
    # shellcheck: global disable arithmetic # applies to rest of file
    # shellcheck: global disable all enable errors enable redirection enable 
    # shellcheck: global quiet
    # shellcheck: global normal
    # shellcheck: global nitpick
    # shellcheck: global lint

[bittorf]

@kurahaupo please open another issue for your suggestions