Shellcheck: Unable to disable SC1008 from disable directive?

[cdrice]

• Rule Id: SC1008
• My shellcheck version: 0.4.6 / online
• [X] 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:

#! /bin/nsh
# shellcheck shell=bash disable=SC1008
exit 0

(I've also tried variations splitting up re-ordering the shell and disable directives - each resulted in the same failure, below).

Here's what shellcheck currently says:

$ shellcheck myscript

Line 1:
#! /bin/nsh
^-- SC1008: This shebang was unrecognized. Note that ShellCheck only handles sh/bash/dash/ksh.

$ 

Here's what I wanted or expected to see:

$ shellcheck myscript
No issues detected!

$ 

---

I have scripts written for BMC BladeLogic network shell (nsh). While nsh could be a separate dialect, I do not expect it is popular enough to warrant development/upkeep, but it _should_ be a valid subset of bash for linting purposes.

I have attempted to force shellcheck to use the bash dialect, both from the shell directive, as well as from the command line as -s bash, but I still receive SC1008 (and RC=1). Even using the disable directive to block SC1008, I still receive SC1008 (and RC=1), which causes my automatic build/lint wrapper around shellcheck to fail unnecessarily for my nsh scripts.

Is it possible to avoid/ignore this particular error being reported? I would expect the disable directive to cover it, but it appears not to.

Note that I _cannot_ change my shebang line, or the code will be invalid for BMC BladeLogic.

As a workaround, I appear to be able to use -e SC1008 as an option to shellcheck (via command line or using SHELLCHECK_OPS). It seems the behavior for blocking this particular error is inconsistent for a comment directive vs. command-line option.

Thanks!

[disassembler]

I have the same issue here using nix-shell for the shebang. It's a bash script, but I need to include some dependencies. It seems this is a chicken and egg problem. The first line has to be the shebang, and shellcheck processes the first line before getting to the 3rd line that tries to disable SC1008 and force set the shell.

Example:

#!/usr/bin/env nix-shell
#!nix-shell -i bash -p qemu jq ec2_api_tools awscli

# shellcheck shell=bash disable=SC1008

#!/usr/bin/env nix-shell
^-- SC1008: This shebang was unrecognized. Note that ShellCheck only handles sh/bash/dash/ksh.

[fm4tt0s]

I have the same issue with SC1008. Im working on a shell additions file and it doesnt ignore the shebang directive at all. Although SC2096 - which has very similar purpose - is processed fine

````

!/usr/bin/env echo run from bash: .

.bashrc

shellcheck shell=bash disable=SC2096,SC1008

true
````

````
$ shellcheck test

In test line 1:

!/usr/bin/env echo run from bash: .

^-- SC1008: This shebang was unrecognized. Note that ShellCheck only handles sh/bash/dash/ksh.
````

[koalaman]

You say you can reproduce it on the latest commit on shellcheck.net. How? This is what I tried:

#! /bin/nsh
# shellcheck shell=bash disable=SC1008
exit 0

and this is what I got:

$ shellcheck myscript
No issues detected!

$ 

[fm4tt0s]

Correct. Im running 0.5.0 on MacOS, installed thru brew

$ shellcheck -V
ShellCheck - shell script analysis tool
version: 0.5.0
license: GNU General Public License, version 3
website: https://www.shellcheck.net

$ brew info shellcheck
shellcheck: stable 0.5.0 (bottled), HEAD
Static analysis and lint tool, for (ba)sh scripts
https://www.shellcheck.net/
/usr/local/Cellar/shellcheck/0.5.0 (8 files, 7MB) *
  Poured from bottle on 2018-08-22 at 15:25:30
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/shellcheck.rb
==> Dependencies
Build: cabal-install ‚úò, ghc ‚úò, pandoc ‚úò
==> Options
--HEAD
        Install HEAD version

$ brew upgrade shellcheck
Error: shellcheck 0.5.0 already installed

$ cat test 
#!/usr/bin/env echo run from bash: .
# .bashrc
#   shellcheck shell=bash disable=SC2096,SC1008
true

$ shellcheck test 

In test line 1:
#!/usr/bin/env echo run from bash: .
^-- SC1008: This shebang was unrecognized. Note that ShellCheck only handles sh/bash/dash/ksh.

[fm4tt0s]

Any updates on this? Thanks.

[koalaman]

The latest commit does not emit SC1008 at all when specifying -s bash or shell=bash. This was fixed in 5005dc0f. 0.5.0 is a stable release that's currently ~60 commits behind master.

However, there is a minor cosmetic issue in trying to squash the warning without specifying the shell if you only use a disable directive. This should be fixed, though it's obviously not a high pri issue since a shell directive does the same thing but better.

[fm4tt0s]

Appreciate the reply. I wanna stay on brew package (easy to admin) so will keep stick on that.

[cdrice]

You say you can reproduce it on the latest commit on shellcheck.net. How?

Regarding my original report (from August 2017), I confirm that now (September 2018), using shellsheck.net, I see the desired (no error) behavior from the original code:

#! /bin/nsh
# shellcheck shell=bash disable=SC1008
exit 0

as well as (simplified to only use shell directive vs. disable):

#! /bin/nsh
# shellcheck shell=bash
exit 0

The error continues to be displayed for using only disable:

#! /bin/nsh
# shellcheck disable=SC1008
exit 0

which aligns with your comment:

However, there is a minor cosmetic issue in trying to squash the warning without specifying the shell if you only use a disable directive. This should be fixed, though it's obviously not a high pri issue since a shell directive does the same thing but better.

From my perspective, being able to suppress this error via # shellcheck shell=bash, would make me quite happy - I look forward to this being released as the stable build (I rely on the stable build for linux x86_64, which is currently at 0.5.0; as noted above, this fix is not included yet). Thanks!

[ghost]

Hello,
apologize for interfere this communication.
The same strange message shellcheck show in case:

!/bin/false

^-- SC1008: This shebang was unrecognized. Note that ShellCheck only handles Bourne based shells.

I use this shebang in files which cannot be launched stand-alone but have to be included in other one using . file.sh or source file.sh (see wikipedia).