8 ms·

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 lin

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.

9dev 2y ago
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 :-)
- Aeolun 2y ago
  I think a lot of people jump to Go because it’s nearly as convenient as bash for writing shell scripts?
  - sgarland 2y ago
    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.
    - tambourine_man 2y ago
      Completely agree. 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.
      - xolox 2y ago
        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.
      - ndsipa_pomu 2y ago
        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).
        tambourine_man 2y ago
        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”.
  - ndsipa_pomu 2y ago
    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.
ndsipa_pomu 2y ago
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.
- xyzzy_plugh 2y ago
  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.
  - ndsipa_pomu 2y ago
    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.
    - Aeolun 2y ago
      I think it’s because: > 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.
sgarland 2y ago
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.
lilyball 2y ago
What sort of noise do you see? I find it's pretty rare to run into something that needs to be suppressed.
- xyzzy_plugh 2y ago
  It's been so long since I used it seriously I couldn't tell you. 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+is%3Aopen+%22false+positive%22 https://github.com/koalaman/shellcheck/issues?q=is%3Aissue+i...
plorkyeran 2y ago
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.

9dev 2y ago

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 :-)

Aeolun 2y ago
I think a lot of people jump to Go because it’s nearly as convenient as bash for writing shell scripts?
- sgarland 2y ago
  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.
  - tambourine_man 2y ago
    Completely agree. 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.
    - xolox 2y ago
      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.
    - ndsipa_pomu 2y ago
      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).
      - tambourine_man 2y ago
        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”.
- ndsipa_pomu 2y ago
  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.

ndsipa_pomu 2y ago

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.

xyzzy_plugh 2y ago
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.
- ndsipa_pomu 2y ago
  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.
  - Aeolun 2y ago
    I think it’s because: > 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.

sgarland 2y ago

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.

lilyball 2y ago

What sort of noise do you see? I find it's pretty rare to run into something that needs to be suppressed.

xyzzy_plugh 2y ago
It's been so long since I used it seriously I couldn't tell you. 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+is%3Aopen+%22false+positive%22 https://github.com/koalaman/shellcheck/issues?q=is%3Aissue+i...

plorkyeran 2y ago

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.