Shellcheck: New directive to stop processing until the end of the file

[gvlx]

There should a new directive to instruct shellcheck to stop processing one it reaches that line.

I sometimes have the need to inline certain foreign scripts (awk, perl, sed, etc.) in the end of the script so it can made self-contained, deployed easily and easily maintainable (regular heredocs can quickly become cumbersome to manage as they sit next to the code).

At some version in the past, setting the following instruction (without a directive) would work, ignoring any lines after it:
# shellcheck disable

For new checks and feature suggestions

• [x] shellcheck.net (i.e. the latest commit) currently gives too many warnings about this to be useful
• [x] I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

Here's a snippet that shows the problem:

#!/bin/bash


read_inline_doc(){
    local __sed__;
    __sed__=$(command -v sed);

    # shellcheck disable=SC2016
    "${__sed__}" \
        '1,/[B]EGIN DEFINITION/d;/[E]ND DEFINITION/,$d;'  \
        "${BASH_SOURCE[0]}";
}

read_inline_doc;

exit 0; # do not allow script to run into here docs
#---------------------------- end of script ----------------------------

#--------------------------- HEREDOC CONTENT ---------------------------
#
#BEGIN DEFINITION
my %perl_hash= (
    one => '1',
    two => '2',
);
#END DEFINITION
#
#------------------------- END OF HEREDOC CONTENT ----------------------

Here's what shellcheck currently says:

It will try to interpret the heredoc, which most certainly will fail;

Here's what I wanted or expected to see:

nothing - ignores the inlined heredoc
or prints a warning to note the analysis was stopped at that line.

Workaround

There is an workaround but it will not generate any warnings about the skipped processing: surrounding the entire HEREDOC CONTENT in quotes makes shellcheck ignore the whole block, as in this example:

#!/bin/bash


read_inline_doc(){
    local __sed__;
    __sed__=$(command -v sed);

    # shellcheck disable=SC2016
    "${__sed__}" \
        '1,/[B]EGIN DEFINITION/d;/[E]ND DEFINITION/,$d;'  \
        "${BASH_SOURCE[0]}";
}

read_inline_doc;

exit 0; # do not allow script to run into here docs
#---------------------------- end of script ----------------------------
"
#--------------------------- HEREDOC CONTENT ---------------------------
#
#BEGIN DEFINITION
my %perl_hash= (
    one => '1',
    two => '2',
);
#END DEFINITION
#
#------------------------- END OF HEREDOC CONTENT ----------------------
"

This is not a priority feature.

[Dmole]

I guess that would be easy to implement but having more than one language in a file is a bug so really you should have a tool that mixes your files together for deployment and shellcheck/Perl::Lint before they're mixed.

[ZxMYS]

I disagree. having multiple languages in a file should not be considered a bug but a common pattern; anyways a global disable flag is desirable regardless of whether this is a bug or not.

[matthewpersico]

My USD 0.02: I just did a quick test. Running this:

#!/bin/bash
echo hi
ishk-)*(
exit 0;
ishk-)*(

gives:

./x: line 5: syntax error near unexpected token `)'
./x: line 5: `ishk-)*('

However, running this:

#!/bin/bash
echo hi
exit 0;
ishk-)*(

gives:

So, in theory, anything after an exit should be ignored by shellcheck because bash ignores it. HOWEVER, it gets tricky. What if you end your script like:

if foo
then 
exit 1
else
exit 0
fi

Bash will never see anything past this block. But can shellcheck do that kind of static analysis? And if it can, then what it should REALLY do is put out an error "SC6789: Unreachable code after exit." And then you'd simply add a disable for 6789 before your other-language code. BUT those disables are really line-based not block based. Unless you then put your other code in a bash block.

And at that point, you might as well put it in a heredoc.

[koalaman]

ShellCheck currently can't do that: it doesn't build a proper control flow graph, which hampers a lot of analysis including dead code detection. I've been wanting to do that for years, but haven't found the time.

Bash is a tricky language to do this for, but ShellCheck is fortunate in that it's not an optimizing compiler that needs to always be correct. For example, in all these cases, the unreachable code can technically be reached if the script was invoked with an exported function exit() { true; }

[matthewpersico]

Then heredoc it is.