4 ms·
I would never trust a DB migration tool written in Bash.
by oweiler 6y ago
I would never trust a DB migration tool written in Bash.
- rapsey 6y agoAgreed. This looks like a monstrosity.
- lsferreira42 6y agoI 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?
- jjeaff 6y agoI think we should keep comments in perspective. All large bash scripts look like a monstrosity. As far as bash scripts go, this one looks well done.
- AdmiralAsshat 6y agoCounterpoint: 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.
- NegativeLatency 6y agoAfter looking at this repo id wager python that did the same thing would be much shorter and easier to read
- nerdponx 6y agoNot to mention there is much better development tooling for Python: test suite runners, static type checkers, and at least one powerful IDE.
- yjftsjthsd-h 6y agoIt'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.
- lolptdr 6y agoGenuine ignorance on my part: why is that?
- judge2020 6y agoFor one, No checks are done to ensure dependencies exist before running a script unless done explicitly.
- x87678r 6y agoFrom Google Style Guide > 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. https://google.github.io/styleguide/shellguide.html https://google.github.io/styleguide/shellguide.html 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.
- Quekid5 6y agoSome 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.
- boudin 6y agoIf it's well written, it can do a better job than a badly written tool in any other language.