> If you are writing a script that is more than 100 lines long, or that uses non-straightforward control flow logic, you should rewrite it in a more structured language now.
Sorry I hate to write snarky comments. The page says other tools have too many dependencies where this doesn't. That makes it a potentially valuable tool. If it works that's great.
Some of their style guides are a bit... particular to their situation, but this one I absolutely agree with.
There are so many pitfalls, so many weird interactions with pipes and error conditions in subprocesses, signals(!), etc. etc. that it can be hard to write even "bail as soon as ANYTHING goes wrong" logic.
(And that's not even accounting for things like "rm -rf $FOO/" going wrong. The shell fully embraced Stringly Typed Programming and this is the inevitable result.)
I have recently learned of linters and such for bash/sh scripts, but that's a bandaid at best.
Counterpoint: I've seen enough tools written in C/Python/Java that are just issuing hard-coded SQL statements on the backend, so, at least with the Bash script I can at least inspect what it's doing before running it.
It's not like BASH is special and doesn't have any tooling. You can test BASH just as well as anyting else, use shellcheck for linting/checking, it has editor support, etc.
I dont think this type of negativity towards a shipped project do any good for any of us, why dont you start reading it's source code and telling him how can this be more secure?
