Nowhere in this list did I see “use shellcheck.”
On the scale of care, “the script can blow up in surprising ways” severely outweighs “error messages are in red.” Also, as someone else pointed out, what if I’m redirecting to a file?
On the scale of care, “the script can blow up in surprising ways” severely outweighs “error messages are in red.” Also, as someone else pointed out, what if I’m redirecting to a file?
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.
There's over 1000 open issues on the GitHub repo, and over 100 contain "false positive". I recognize several of these at first glance.
https://github.com/koalaman/shellcheck/issues?q=is%3Aissue+i...
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.
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).
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.
If that doesn't track with you, that's cool, I'm happy for you.
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.
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'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 think the huge number of footguns is what makes BASH scripting fun.
We have a completely different definition of fun.
I really only use bash when I need to chain a few commands. As soon as there is more complex logic I move to some programming language.
If it's useful for you, then wonderful!
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.
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.
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.
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 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 :)
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.