Hacker News Reader

Comment by xyzzy_plugh | Hacker News Reader

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.

View on HN

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.

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.

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.

> 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.

People should learn to take constructive criticism and harsh truths better. I saw nothing unkind with that comment.

I wouldn't say it's unkind, but I do take issue with "it's worth changing how you write scripts" because, at least for me, it isn't.

If it's useful for you, then wonderful!

I read it as "when in Rome...".

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?

I think you're misunderstanding my position. Either way, this is not a constructive comment. It contributes nothing to the discussion.

Reply on news.ycombinator.com