I find shellcheck to be a bit of a nuisance. For simple one-shot scripts, like cron jobs or wrappers, it's fine. But for more complicated scripts or command line tools, it can have a pretty poor signal-to-noise ratio. Not universally, but often enough that I don't really reach for it anymore.
In truth when I find myself writing a large "program" in Bash such that shellcheck is cumbersome it's a good indication that it should instead be written in a compiled language.
I’ve definitely hit places where shellcheck is just plain wrong, but I’ve started to just think of it as a different language that’s a subset of shell. It’s less of a linter and more like using gradual type checking, where there’s no guarantee that all valid programs will be accepted; only that the programs which are accepted are free of certain categories of bugs.
If ShellCheck is spitting out lots of warnings, then it'd be worth changing your shell writing style to be more compliant with it. Simple things like always putting variables in quotes should prevent most of the warnings. If anything, long scripts benefit far more from using ShellCheck as you're more likely to make mistakes and are less likely to spot them.
For the false positives, just put in the appropriate comment to disable ShellCheck's error ahead of that line e.g.
# shellcheck disable=SC2034,SC2015
That stops the warning and also documents that you've used ShellCheck, seen the specific warning and know that it's not relevant to you.
Thanks but I'm not really asking for advice. I'm uninterested in changing how I write correct, often POSIX-compliant shell scripts because of a linter that has an inferior understanding of the language. I'm also not a fan of this kind of dogmatic application of tools. Shellcheck can be useful sure, but my point is that, at least for me, the juice is often not worth the squeeze. I'm aware of how to disable rules. I often find the whole endeavor to be a waste of time.
If that doesn't track with you, that's cool, I'm happy for you.
That's an odd way to respond to someone who's trying to be helpful.
I find that there's a lot of good information in the comments on HackerNews, so sometimes advice and recommendations aren't just designed for the parent comment.
Your reply adds nothing of value and comes across as being rude - you could have simply ignored my comment if you found it of no value to you.
> If ShellCheck is spitting out lots of warnings, then it'd be worth changing your shell writing style to be more compliant with it.
Is just a very roundabout way of saying ‘If you get a lot of errors using shellcheck you are doing it wrong’, which may or may not be true, but it’d make anyone defensive.
You could be right - I certainly didn't intend my comment to be antagonistic.
My experience of ShellCheck is that you only get loads of warnings when you first start out using it and it finds all of your unquoted variables. Once you get more experienced with writing scripts and linting them with ShellCheck, the number of warnings should dramatically reduce, so it seems odd that an experienced script writer would be falling foul of ShellCheck being pedantic about what you're writing.
> ‘If you get a lot of errors using shellcheck you are doing it wrong’
I kind of agree with that, although a lot of ShellCheck's recommendations might not be strictly necessary (you may happen to know that a certain variable will never contain a space), it's such a good habit to get into.
> it seems odd that an experienced script writer would be falling foul of shellcheck being pedantic about what you're writing.
It's not simply being pedantic, it is wrong. Your writing gives the impression that the tool is infallible.
If I was new to writing shell scripts, shellcheck is clearly a wise choice. The language is loaded with footguns. But as someone who has been writing scripts for decades, I already know about all the footguns. My experience with shellcheck is that it mostly finds false positives that waste my time.
I do agree about ShellCheck being wrong sometimes - that's why I mentioned the method of disabling it for specific lines with a comment. When I first started using ShellCheck, it was highlighting lots of footguns that I wasn't aware of, but nowadays, it's very rare for it to spit a warning out at me - usually just for something like it not following a script or stating that a variable wasn't defined when it was.
I think the huge number of footguns is what makes BASH scripting fun.
Adopting any kind of quality assurance tool is implicitly buying into its "opinionated" worldview. Forfeiting one's autonomy for some person(s) notions of convention.
Rephrased: Using shellcheck is a signal to potential user's, per the Principal of Least Astonishment. No matter if either party doesn't particularly care for shellcheck; it's just a tool to get on the same page more quickly.
Yeah, there's that aspect to it as well. It's like using a coding convention - the reason behind the conventions may not be applicable for every time that you write a variable name, but I think they're good habits to get into.
e.g. I always put BASH variables in curly braces and double quotes which is often unnecessary (and more verbose), but it means that I don't trigger any ShellCheck warnings for them and it's easier to just type the extra characters than thinking about whether or not they'll actually make any difference.
Shellcheck, and really any linter (and arguably also any other form of programming language safety, like static typing or compile-time memory safety), is not there for the very experienced author (which it sounds like you are).
Those mechanisms exist for the inexperienced author (especially in a team setting) where you want some minimum quality and consistency.
An example where Shellcheck might be useful for you is when working with a team of junior programmers. You don't necessarily have the time to teach them the ins and outs of bash, but you can quickly setup Shellcheck to make sure they don't make certain types of errors.
I think your position is totally valid and nobody can or should force you to use a linter, but I think that even for you there _can_ be situations where they might be useful.
Personally I disagree, but can understand your point.
I think I'm fairly experienced in shell and Python (~20 and ~8 YOE, respectively), and still find value in linters, type checkers, etc. Maybe moreso in Python, but that's probably a function of me writing larger programs in Python than in shell, and usually changing my mind on something as I'm writing it.
I agree that there is value even for very experienced users. A good example of this is how expert C/C++ programmers still make mistakes with memory management -- memory safe languages benefits beginners and experts equally in this case.
I personally setup linters/formatters/other static analysis for solo projects, even for languages I know very well.
I just didn't want to write a comment large enough to capture all of the nuance :)
This is one of the worst takes I've ever heard. People like you are the reason code breaks and kills people (or destroys property, etc.). Do you also refuse to use calculators, under the pretense of being too experienced, and as such calculating the square roots of four-digit numbers by hand?
It doesn’t already need to be a compiled language, that’s kind of like noticing you’re not going to walk down a mile to the pharmacy and decide to take a Learjet instead. The gradient should include Python or similar scripting languages before you reach for the big guns :-)
People say that (and the same for Python), but I just don’t get it – and I’m a huge fan of Python.
With shell, I can take the same tools I’ve already been using as one-liners while fiddling around, and reuse them. There is no syntax mapping to do in my head.
With any other language, I have to map the steps, and probably also add various modules (likely within stdlib, but still). That’s not nothing.
I’ve rewritten a somewhat-complicated bash script into Python. It takes some time, especially when you want to add tests.
I have a rule that if I’m using arrays I should move to Python, PHP, etc. It’s a nice red flag. Arrays in Bash are terrible and a sign that things are getting more complicated.
Akshuaaaly, I think you'll find that any BASH script uses an array for the command line arguments.
Personally, I'm fine with BASH arrays (even associative ones) and yes, the syntax can be opaque, but they get the job done. I find that the long-term advantages of BASH outweigh the many, many problems with it. (If you want something to keep running for 20 years on a variety of different machines and architectures, then BASH is easier to manage than almost any other language).
Command line argument parsing is already a complicated issue in Bash. It’s not a hard rule, but whenever I have to Google Bash’s array syntax I think to myself “stop it now, you’ll regret it”.
I use the same heuristic for when I should switch from shell to Python :-). Arrays (especially associative ones, at least for me) are a good indication that a more advanced language like Python might be more appropriate than shell.
It hasn't got the same level of cross compatibility though. I can just copy a BASH script from some x86 machine and it'll run just fine on an ARM processor.
I feel like that should be reversed. If you’re writing a tiny script, the odds that you’ll make a critical mistake is pretty low (I hope).
As others have pointed out, you can tune shellcheck / ignore certain warnings, if they’re truly noise to you. Personally, I view it like mypy: if it yells at me, I’ve probably at the very least gone against a best practice (like reusing a variable name for something different). Sometimes, I’m fine with that, and I direct it to be ignored, but at least I’ve been forced to think about it.
In truth when I find myself writing a large "program" in Bash such that shellcheck is cumbersome it's a good indication that it should instead be written in a compiled language.