shellcheck
shellcheck copied to clipboard
Request: Support PKGBUILD files
Arch Linux's PKGBUILD is a shell script with a few differences:
- It does not have shebang
- Most variables are used by
makepkg
but are marked as unused (SC2034) byshellcheck
- Some variables (such as
$srcdir
) are provided bymakepkg
but are marked SC2164 byshellcheck
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).