Request: Support PKGBUILD files

[KSXGitHub]

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) by shellcheck
• Some variables (such as $srcdir) are provided by makepkg but are marked SC2164 by shellcheck

Example PKGBUILD

[gromgit]

There's an app for that: https://github.com/vn971/rua

[KSXGitHub]

@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.

[KSXGitHub]

@gromgit Actually, one .shellcheckrc file is enough. Do you if there is a .shellcheckrc for PKGBUILD?

[gromgit]

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.

[Freed-Wu]

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

[Freed-Wu]

Can any PR about it (let PKGBUILD be recognized as bash) be accpeted?

[WhyNotHugo]

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.

[WhyNotHugo]

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).

[Freed-Wu]

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

[brother]

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$ 

[Freed-Wu]

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.

[RubenKelevra]

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.

[austin987]

If it's not that big of a deal, then someone interested on it should send a pull request to implement the feature.

[RubenKelevra]

@austin987 why? Learning an obscure language just for the sake of a PR makes no sense.

[austin987]

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).

[Freed-Wu]

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.

[RubenKelevra]

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.

[Freed-Wu]

I rethink #1843 (comment). We can refer typescript's *.d.ts to create *.d.sh.

For example, when we edit PKGBUILD, shellcheck will source PKGBUILD.d.sh and know some variables.
so it will not warn those vairables.

A magic comment can be # shellcheck defintion=PKGBUILD.d.sh or
# shellcheck defintion=https://a_URL_like_DefinitelyTyped/PKGBUILD.d.sh

If bash-language-server support type annotation,
we can use same *.d.sh.

[a-priestley]

@Freed-Wu Adding magic comments would be less than ideal in my opinion when you are contributing to a file maintained by someone who isn't using bash-ls.
What about expanded args for shellcheck to specify which variables should be ignored? Something like shellcheck -e "pkgname,pkgver=SC2034 srcdir,pkgdir=SC2154".