new check: Avoid using keywords as variable names

[jldugger]

For whatever reason, defining variables like 'continue' or 'for', which are already keywords, is allowed in bash. I'm thinking it'd be a good idea to flag this in shellcheck.

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

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

example() {
        local for
        for="no way no how"
        for in in $for; do
            echo $in
        done;
}

Here's what shellcheck currently says:

No issues detected!

Here's what I wanted or expected to see:

SCWhateves: don't use keywords as variables [4, 4]

[lambdax-x]

Bash manual says:

RESERVED WORDS
Reserved words are words that have a special meaning to the shell. The following words are recognized as reserved when unquoted and either the first word of a simple command (see SHELL GRAMMAR below) or the third word of a case or for command:

  ! case  coproc  do done elif else esac fi for function if in select then until while { } time [[ ]]

Which means reserved words aren't specified to not be used as variable names. I am totally against using them as variable, it would be insane to do that but it is not forbidden from the bash manual point of view. I am not sure there are cases where it fucks up bash but from what I tried in my shell, it never broke it. Are you aware of such constructions?

So from bash point of view, this is perfectly legal while being crazy:

#! /usr/bin/env bash

echo "$let"
let let++
echo "$let"

if false
then
    echo "wont echo"
    else="esle"
    echo "wont echo"
    fi=666
else
    echo "will echo"
    else="else"
    echo "will echo"
    fi=1.618
fi

echo "else=$else"
echo "fi=$fi"

If ShellCheck does not aim to warn such constructions, what about a pendantic mode forbidding them?

[lambdax-x]

The manual also indicates in the Shell Function Definitions paragraph:

[...] When in posix mode, name may not be the name of one of the POSIX special builtins. [...]

But I guess it would be great to warn when a function is shadowing a builtin.

[jldugger]

. I am not sure there are cases where it fucks up bash but from what I tried in my shell, it never broke it. Are you aware of such constructions?

I haven't encountered any, but I have yet to see a valid use case. It seems far more likely for someone to mistakenly reuse a keyword than than to intentionally do this. And doing so probably does a number on most syntax highlighting engines.