Bug 1507505 - ShelLCheck 0.4.5 does not honor file scope "shellcheck disable=SC2181"
Summary: ShelLCheck 0.4.5 does not honor file scope "shellcheck disable=SC2181"
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: ShellCheck
Version: 26
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Dridi Boukelmoune
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-30 12:54 UTC by Jeffrey Walton
Modified: 2017-11-14 10:58 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-14 10:58:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jeffrey Walton 2017-10-30 12:54:31 UTC
I'm working on Fedora 26 x86_64 (fully patched). I have ShellCheck 0.4.5 installed from the Fedora repos.

Checking a shell script with SC2181 disabled still produces SC2181 warnings:

  git clone https://github.com/weidai11/cryptopp.git
  shellcheck cryptest.sh | grep -i -c SC2181
  68

To disable the warning, the following was added after the shebang and before any commands:

  # Keep the noise down
  # shellcheck disable=SC2181

The same exercise on Ubuntu 17 with ShellCheck 0.4.4 does not witness the problem. Others on Stack Overflow cannot reproduce the problem either. Also see https://stackoverflow.com/q/47014776/608639 .

**********

$ yum info shellcheck
Installed Packages
Name         : ShellCheck
Version      : 0.4.5
Release      : 3.fc26
Arch         : x86_64
Size         : 6.0 M
Source       : ShellCheck-0.4.5-3.fc26.src.rpm
Repo         : @System
From repo    : fedora
Summary      : Shell script analysis tool
URL          : https://github.com/koalaman/shellcheck
License      : GPLv3+
Description  : The goals of ShellCheck are:
             :
             : * To point out and clarify typical beginner's syntax issues,
             :   that causes a shell to give cryptic error messages.
             :
             : * To point out and clarify typical intermediate level semantic
             :   problems, that causes a shell to behave strangely and
             :   counter-intuitively.
             :
             : * To point out subtle caveats, corner cases and pitfalls, that
             :   may cause an advanced user's otherwise working script to fail
             :   under future circumstances.

Comment 1 Jens Petersen 2017-11-02 04:10:46 UTC
I tested and can't reproduce on my F26 machine.

Could you attach your diff for cryptest.sh?


[cryptopp:master]$ git diff -U1
diff --git a/cryptest.sh b/cryptest.sh
index cc4a737..6ed7b4f 100755
--- a/cryptest.sh
+++ b/cryptest.sh
@@ -1,3 +1,3 @@
 #!/usr/bin/env bash
-
+# shellcheck disable=SC2181
 # cryptest.sh - written and placed in public domain by Jeffrey Walton and Uri Blumenthal.
[cryptopp:master]$ shellcheck cryptest.sh | grep -i -c SC2181
0

Comment 2 Jeffrey Walton 2017-11-13 15:39:52 UTC
(In reply to Jens Petersen from comment #1)
> I tested and can't reproduce on my F26 machine.
> 
> Could you attach your diff for cryptest.sh?
> 
> 
> [cryptopp:master]$ git diff -U1
> diff --git a/cryptest.sh b/cryptest.sh
> index cc4a737..6ed7b4f 100755
> --- a/cryptest.sh
> +++ b/cryptest.sh
> @@ -1,3 +1,3 @@
>  #!/usr/bin/env bash
> -
> +# shellcheck disable=SC2181
>  # cryptest.sh - written and placed in public domain by Jeffrey Walton and
> Uri Blumenthal.
> [cryptopp:master]$ shellcheck cryptest.sh | grep -i -c SC2181
> 0

Thanks Jens.

I think this has something to do with libraries installed in /usr/local/lib64. I often build typical libraries with different settings and insatlly them in /usr/local. The libraries include GetText, Readline, OCRE, etc. The problem is, I can't tell the Linux loader that programs in /bin and /usr/bin (like shellcheck) should _not_ to use the new libraries (in /usr/local). The runtime link loader is just too braindead to understand the simple policy.

I suggest you close this report as "can't duplicate".

Comment 3 Jens Petersen 2017-11-14 10:58:06 UTC
Okay thanks


Note You need to log in before you can comment on or make changes to this bug.