Re: [PATCH] [pre-commit] Add shellcheck

[Tom de Vries <tdevries@suse.de>]

On 6/22/26 7:48 AM, Thiago Jung Bauermann wrote:
> Simon Marchi <simark@simark.ca> writes:
> 
>> On 2026-06-18 11:19, Tom de Vries wrote:
>>> I found a pure python implementation of shellcheck [1].
>>>
>>> Use it to run shellcheck on scripts in the repo.
>>>
>>> Exclude any scripts that are not currently clean.
>>>
>>> Running it seems reasonably fast:
>>> ...
>>> $ pre-commit run shellcheck --all-files -v
>>> shellcheck...............................................................Passed
>>> - hook id: shellcheck
>>> - duration: 0.06s
>>> ...
>>>
>>> For information on other solutions, see this RFC [2].
>>>
>>> [1] https://pypi.org/project/pureshellcheck/0.2.2/
>>> [2] https://sourceware.org/pipermail/gdb-patches/2024-November/213400.html
>>
>> While I'm sympathetic to the use of pre-commit (I added the first
>> hooks), I'm starting to get a bit worried that we kind of blindly pull
>> hooks from random places without paying much attention.  This is going
>> to get executed on the machines of many GDB devs, and probably some CI
>> too.
>>
>> I had this thought because this one has the "random project on github
>> vibes" (it appears to be a vibe coded project started a week ago).  More
>> established projects (like black) are not immune to being compromised,
>> but they are easier to trust I guess.
> 
> I have the same kind of concern, but I'm more paranoid. As a general
> principle I prefer to install distro packages rather than
> language-specific packages (such as the ones from PyPI), on the
> assumption that distros tend to be more careful about incorporating
> packages and updating them (it's a weak assumption though).
> 
> Because of that, in order to run the pre-commit checks I created a
> script (attached) that parses .pre-commit-config.yaml and runs the hooks
> with the tools that are already installed on the system. It doesn't try
> to download anything.
> 
> Today I added support for running each hook in an isolated container
> with access only to the binutils-gdb repo, and in read-only mode at
> that. It uses Guix to set up the containers so when Guix isn't installed
> you need to pass the --no-container option.
> 
> Also when using containers the script can only use the tools packaged in
> Guix, which currently doesn't have some of the tools referenced by our
> .pre-commit-config.yaml, or has older versions of them.
> 
> Another bad news is that the script is in Scheme. :)
> 
> But you get the idea. :)
> 

Hi Thiago,

thanks for sharing your point of view and the script.

My take on this is as follows.

The benefit of git hooks is automation.

The benefit of using the pre-commit framework to manage those hooks is:
- version pinning, and
- seamless installation
in other words, making it easy that everybody does the same check.

That comes with the drawback of a download-heavy approach, but that's 
the trade-off.

Your approach has a different trade-off.

We could do something similar (no downloading) for shellcheck:
...
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 9910bbb82f2..92c56d95977 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -130,3 +130,10 @@ repos:
        language: unsupported_script
        entry: gdb/contrib/check-file-mode.sh
        files: '^(gdb|gdbserver|gdbsupport)/.*$'
+    - id: &id5 shellcheck
+      name: *id5
+      language: unsupported
+      entry: shellcheck
+      files: '^(gdb|gdbsupport|gdbserver)/'
+      types: ['shell']
+      exclude: 
'^(gdb/config/djgpp/(djcheck.sh|djconfig.sh)|gdb/contrib/ari/(create-web-ari-
in-src.sh|gdb_ari.sh|update-web-ari.sh)|gdb/contrib/(cc-with-tweaks.sh|gdb-add-index.sh)|gdb/gdb_builda
ll.sh|gdb/gdb_mbuild.sh|gdb/regformats/regdat.sh|gdb/po/gdbtext|gdb/testsuite/lib/pdtrace.in)$|/configu
re$'
...

This means there's no easy installation, people have to install it 
themselves.

There's also no version pinning.  We could add a script that does a 
version check though, and check for version 0.11.0.

My laptop runs Leap 16.0, which has shellcheck 0.10.0, so I would have 
to run pre-commit in a tumbleweed container.  Or build shellcheck from 
source and add it to my path.

But yeah, I'd prefer to not have to bother with that, and pureshellcheck 
does provide an easy solution.

Thanks,
- Tom