Open KSXGitHub opened 4 years ago
There's an app for that: https://github.com/vn971/rua
@gromgit Thanks for your suggestion. However, I do not intend to use shellcheck or rua in the terminal, but rather, as a linter for VS Code.
@gromgit Actually, one .shellcheckrc
file is enough. Do you if there is a .shellcheckrc
for PKGBUILD?
If I read the vscode-shellcheck docs correctly, you really want to set up a separate workspace for PKGBUILD development, and configure the following options therein:
"shellcheck.customArgs": ["-s", "bash"],
"shellcheck.exclude": [2034, 2154]
Of course, that would hide any real SC2034/2154 problems in your PKGBUILD.
Ideally, you'd want something that transforms your PKGBUILD source into something that Shellcheck can check as a proper shell script, then somehow map the results back to your original source. I've raised an issue for this: see #1844.
Just let shellcheck disable SC2148/2034 for PKGBUILD
. Maybe it can become a default option.
https://github.com/koalaman/shellcheck/wiki/Ignore#ignoring-all-errors-in-a-file-08
Before:
After:
Update:
Add this line to your PKGBUILD
(and build.sh
for termux and ebuild
for gentoo).
# shellcheck shell=bash disable=SC2034
Can any PR about it (let PKGBUILD be recognized as bash) be accpeted?
There's a very similar situation with APKBUILD
(expect the fact that these are sh
, not bash
).
However, I would globally ignore SC2148/SC2034
. Only some specific variables are used by the build system; other unused variables are valid warnings.
I think it would be useful is variables could be ignored by name (rather than putting the directive on the line above where they are declared).
Create ~/.shellcheckrc
can stop shellcheck warning:
shell=bash
disable=SC2034,SC2154
However, Why it cannot support configuration for different filenames like editorconfig? Such as:
[{PKGBUILD,build.sh,*.{install,ebuild,subpackage.sh}}]
shell=bash
disable=SC2034,SC2154
It will disable SC2034,SC2154 for Archlinux's PKGBUILD, *.install
, and Gentoo Linux's *.ebuild
, Android Termux's build.sh, *.subpackage.sh
, while it won't disable any warning for common shell scripts.
Or just use editorconfig format. See #2128
Shellcheck will traverse the folder structure backwards to find the shellcheckrc file. Using that knowledge you could choose to place the .shellcheckrc
in the root of the project if that is any help between "inline" and "user home folder".
brother /tmp/a$ tree -a
.
├── b
│ └── c
│ └── d
│ └── e
│ └── test.sh
└── .shellcheckrc
5 directories, 2 files
brother /tmp/a$ cat .shellcheckrc
disable=SC2154
brother /tmp/a$ cd b/c/d/e/
brother /tmp/a/b/c/d/e$ shellcheck test.sh
In test.sh line 3:
echo $help
^---^ SC2086 (info): Double quote to prevent globbing and word splitting.
Did you mean:
echo "$help"
For more information:
https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent globbing ...
brother /tmp/a/b/c/d/e$ rm /tmp/a/.shellcheckrc
brother /tmp/a/b/c/d/e$ shellcheck test.sh
In test.sh line 3:
echo $help
^---^ SC2154 (warning): help is referenced but not assigned.
^---^ SC2086 (info): Double quote to prevent globbing and word splitting.
Did you mean:
echo "$help"
For more information:
https://www.shellcheck.net/wiki/SC2154 -- help is referenced but not assign...
https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent globbing ...
brother /tmp/a/b/c/d/e$
Shellcheck will traverse the folder structure backwards to find the shellcheckrc file
I hope it can become a global settings, that is, when this file name is PKGBUILD
, SC2034,SC2154
will be ignored.
Sad that there's still no support for PKGBUILDs. Ignoring all warnings isn't really helpful either, as they could be valid.
ShellCheck would just need to know that some variables are used outside the context and some are supplied. Isn't really THAT big of a deal in being implemented.
If it's not that big of a deal, then someone interested on it should send a pull request to implement the feature.
@austin987 why? Learning an obscure language just for the sake of a PR makes no sense.
Because it's a FOSS project? If you want something done, either be patient, do it yourself, or pay someone to do the work. You can't demand that someone prioritize your particular issue (I mean, you can, but don't expect it to work).
Return to this question. I think the problem is more complex. PKGBUILD
will be sourced by makepkg
, and some variables like pkgname
, pkgver
will be warned as SC2034. However, if we simpley disable SC2034, the real problem of SC2034 (unused variable) will be ignored together. I think perhaps shellcheck can read a file such as PKGBUILD.conf.sh
, which export pkgname pkgver ...
, before check PKGBUILD
, then the warning SC2034 for pkgname
, pkgver
will be ignored. For gentoo linux's ebuild
, Alpine Linux's APKBUILD
, Android Termux's build.sh
and *.subpackage.sh
, Cygwin's cygbuild
, ... We can use same method to support it.
Because it's a FOSS project? If you want something done, either be patient, do it yourself, or pay someone to do the work. You can't demand that someone prioritize your particular issue (I mean, you can, but don't expect it to work).
I've never demanded anything. I said it's "sad" that it's still not working.
Arch Linux's PKGBUILD is a shell script with a few differences:
makepkg
but are marked as unused (SC2034) byshellcheck
$srcdir
) are provided bymakepkg
but are marked SC2164 byshellcheck
Example PKGBUILD