Feature request: Allow directives in trailing comments

[reidpr]

I would like to be able to specify directives on the same line as the command in order to save vertical space and reduce clutter.

This is similar to, but not a duplicate of, #1267.

(Thanks for your hard work on ShellCheck. I am finding tons of bugs in my code with it.)

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:

#!/bin/bash

CH_RUN_FILE="$(command -v ch-run)"       # shellcheck disable=SC2034
CH_LIBEXEC="$(ch-build --libexec-path)"  # shellcheck disable=SC2034

Here's what shellcheck currently says:

(shellcheck.net as of right now.)

$ shellcheck myscript
 
Line 3:
CH_RUN_FILE="$(command -v ch-run)"       # shellcheck disable=SC2034
^-- SC2034: CH_RUN_FILE appears unused. Verify use (or export if used externally).
                                         ^-- SC1126: Place shellcheck directives before commands, not after.
 
Line 4:
CH_LIBEXEC="$(ch-build --libexec-path)"  # shellcheck disable=SC2034
^-- SC2034: CH_LIBEXEC appears unused. Verify use (or export if used externally).
                                         ^-- SC1126: Place shellcheck directives before commands, not after.

Here's what I wanted or expected to see:

$ shellcheck myscript
No issues detected!

[tomasohara]

Hi, is this hard to implement? Besides clutter, it avoids the checks from applying to subsequent lines. This is what pylint does.

[koalaman]

@tomasohara Are you aware that directives already only apply to the immediate next command, and not any subsequent ones? (The exception is directives between the shebang and first command, which are considered filewide)

[tomasohara]

Thanks for the clarification @koalaman.

Perhaps it would be good to have a warning in the manual that the pylint style is not needed. This would be for the sake of people like myself who use have used pylint before using shellcheck.

By the way, I didn't know what was meant by command-or-structure in the manual. This becomes clearer with the brace example and your explanation, but I think the same line approach is preferable to that of having to introduce blocking. Granted that this makes it a non-trivial change, but that could be addressed with a new option flag (e.g., --same-line-scoping).

Moreover, here's a case where the same-line approach seems better (i.e., only wanting the first violation to be disabled):

¢ diff --side-by-side /home/tomohara/bin/examples/dollar-star-vs-at.bash /home/tomohara/bin/examples/_dollar-star-vs-at.bash | perl -00 -ne 'print if /\|/;'    echo "---------------------"				    echo "---------------------"
    echo Using '"$*"'						    echo Using '"$*"'
    # [s]hellcheck disable=SC2048,SC2066,SC2086			    # [s]hellcheck disable=SC2048,SC2066,SC2086
    #    SC2048: Use "$@" (with quotes) to prevent whitespace	    #    SC2048: Use "$@" (with quotes) to prevent whitespace
    #    SC2066: Since you double quoted this, it will not wo	    #    SC2066: Since you double quoted this, it will not wo
    #    SC2086: Double quote to prevent globbing and word sp	    #    SC2086: Double quote to prevent globbing and word sp
    for param in "$*"; do             # shellcheck disable=SC |	    for param in "$*"; do
	printf '%s\n' "$param"						printf '%s\n' "$param"
	echo $*						      |		echo $*                      # shellcheck disable=SC2
    done;							    done;

The complete scripts are attached:
_dollar-star-vs-at.bash.gz
dollar-star-vs-at.bash.gz

[koalaman]

The current system seemed like a good approach at the time, and still has some benefits, but in retrospect it was a mistake. It would be tricky to support end-of-line comments right now, especially if they can come after something that's not even a command, such as do. I would definitely like to fix this at some point, though there are several other significant rewrites I'd prioritize first.