On Wed, 2020-07-08 at 21:41 +0100, Samuel Henrique wrote: > > Paul Wise <pabs@debian.org> > > It also seems unlikely shellcheck would add a bridge between Haskell > > and Perl of the kind needed to implement custom checks. > > I don't think such a thing is needed, shellcheck already provides > multiple machine-readable output formats, which is the way IDEs > integrate with it. Would you happen to be thinking about some usecase > that is not covered by this? As mentioned in your self reply this wouldn't enable custom checks, but I noticed that morbig's machine-readable output could enable them. > I couldn't find this lintshell project, would you mind to give some > references? It's the first time I'm hearing about it. It is a subset of the CoLiS work Ralf has been working on since 2015: https://www.irif.fr/~treinen/colis/ https://github.com/colis-anr/ https://github.com/colis-anr/lintshell https://debconf19.debconf.org/talks/105-symbolic-execution-of-maintainer-scripts/ https://debconf18.debconf.org/talks/90-mining-debian-maintainer-scripts/ https://debconf16.debconf.org/talks/63/ Ralf: could you link to all the CoLiS talks/presentations you and your team have made from the CoLiS website? > To add to the general discussion, the way I envision this moving > forward is that lintian integrates with linters (by their > machine-readable outputs, just like IDEs) and calls them against the > target files, with the possibility of ignoring checks that we might > agree we don't want. I'd suggest for shellcheck to at least disable the style checks, those are just going to be a lot of noise for many maintainers. > Adding Debian specific checks would depend on a bunch of factors like: > someone contributing directly to the linter tool, upstream accepting > it, and the check per-se making sense to be upstreamed, but most > importantly; providing Debian-specific checks would be a bonus, just > by having plain shellcheck run by default on things like maintscripts > would be a win. It seems unlikely that shellcheck upstream would accept checks that are truly Debian-specific, so I would think a better design would be to add either a plugin system or a machine-readable parse tree output mode to shellcheck. Or just use morbig's existing output. PS: there are a couple of other shell linting tools listed here: https://github.com/collab-qa/check-all-the-things/blob/master/data/sh.ini And also some more are on other lists of linting tools: https://github.com/collab-qa/check-all-the-things/raw/master/doc/TODO PPS: personally I'm not sure lintian is the right place to do generalised application of static/dynamic analysis tools to packages available in Debian. For the lone developer case I mostly like the way the check-all-the-things tool works. I think a centralised service could be based on DACA or Debile, check-all-the-things, maybe other code for more complicated checks, the SARIF interchange format, donated credits on the various cloud services and donated time on hardware owned by individuals and orgs for arch-specific checks. https://wiki.debian.org/qa.debian.org https://github.com/collab-qa/check-all-the-things/issues/4 https://docs.oasis-open.org/sarif/sarif/v2.0/csprd01/sarif-v2.0-csprd01.html -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part