netdev - Re: [ANN] pylint and shellcheck

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c0bc969f-d2d3-4d48-bc6d-00dd299bd7be@intel.com>
Date: Wed, 4 Jun 2025 15:36:25 +0200
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Simon Horman <horms@...nel.org>, Jakub Kicinski <kuba@...nel.org>
CC: <netdev@...r.kernel.org>
Subject: Re: [ANN] pylint and shellcheck

On 6/4/25 09:27, Simon Horman wrote:
> On Tue, Jun 03, 2025 at 12:06:39PM -0700, Jakub Kicinski wrote:
>> Hi!
>>
>> It's merge window time so I have a bit of time to catch up on random
>> things. I added shellcheck, yamllint and pylint:
>> https://github.com/linux-netdev/nipa/commit/c0fe53ae533d19c19d2e00955403fb57c3679084
>> https://github.com/linux-netdev/nipa/commit/255ee0295a096ee7096bebd9d640388acc590da0
>> https://github.com/linux-netdev/nipa/commit/54e060c9094e33bffe356b5d3e25853e22235d49
>> to the netdev patchwork checks.
>>
>> They will likely be pretty noisy so please take them with a grain of
>> salt (pretty much like checkpatch). Using the NIPA scripts from the
>> commits above could be useful to find the delta of new warnings, since
>> there will be quite a few existing ones.
>>
>> I suspect as we get more experience we will find the warning types to
>> disable, and we will drive the number of existing errors down to make
>> checking for new ones less of a pain. As I said, for now please don't
>> take these checks failing at face value.
> 
> Thanks Jakub,
> 
> I agree this is a good step.
> 
> Anecdotally, my feeling from running shellcheck over patches for a little
> while now is that the feedback it gives mainly relates to stricter coding
> practices which aren't generally followed. And yet the scripts seem to run
> reliably in the environments they are intended to run in.
> 
> So I'll be interested to see if we end up go for some mix of disabling
> warnings and updating (creating!) our preferred coding style for shell
> scripts.
> 
> </2c>
> 

other than quoting rules (shellcheck knows/assumes less than a human
could) I find all other shellcheck warnings to be a good thing to avoid
in all codebases (mixed level of bash familiarity of participants)