3 ms·

> Probably easier to stick to bash rather than the overhead of learning new set of commands that I need to learn from scratch. That's all fine and dandy until

by fivea 5y ago

> Probably easier to stick to bash rather than the overhead of learning new set of commands that I need to learn from scratch. That's all fine and dandy until your shell script grows beyond a dozen lines of code or so. The moment that happens, shell scripts become barely readable and terribly hard to maintain, unlike alternatives such as python.

MobiusHorizons 5y ago
I have to say I have not found this to be true. Bash is an excellent glue language if what you want to do is fundamentally a shell like activity (eg composing together other more powerful primitives). I think the key (which is often forgotten) is just to remember to use the abstractions provided by the language (also shell-check, which is the most helpful linter I have ever encountered) If you use functions to aid in abstraction, you can easily convert the function to a program in a more capable language as soon as it becomes too complicated. In the end, I usually find that most of the things people replace good old unix tools with are better in one limited area, but miss a large part of what make the originals magic. Usually this is some combination of universal, discoverable, reduced dependencies, composable abstractions.
drran 5y ago
Refactor your terrible and hard to maintain script into a well looking and maintainable script. It's not a bash fault. My bash-modules[0] project[1] may help you with that. Typically, I perform script refactoring in these steps: 1. Split code into few subroutines with clear boundaries between them, or split a large script into multiple simpler scripts. 2. Add an error handler with transparent message to every line of code. 3. Add command line options to override hard-coded things, to be able to test things in isolation. 4. Write documentation (man-page) for script, for future self. 5. Write test cases. 6. Refactor code, following best practices. [0]: http://vlisivka.github.io/bash-modules/ http://vlisivka.github.io/bash-modules/ [1]: https://github.com/vlisivka/bash-modules https://github.com/vlisivka/bash-modules

by fivea 5y ago

MobiusHorizons 5y ago

I have to say I have not found this to be true. Bash is an excellent glue language if what you want to do is fundamentally a shell like activity (eg composing together other more powerful primitives). I think the key (which is often forgotten) is just to remember to use the abstractions provided by the language (also shell-check, which is the most helpful linter I have ever encountered) If you use functions to aid in abstraction, you can easily convert the function to a program in a more capable language as soon as it becomes too complicated. In the end, I usually find that most of the things people replace good old unix tools with are better in one limited area, but miss a large part of what make the originals magic. Usually this is some combination of universal, discoverable, reduced dependencies, composable abstractions.

drran 5y ago

Refactor your terrible and hard to maintain script into a well looking and maintainable script. It's not a bash fault. My bash-modules[0] project[1] may help you with that. Typically, I perform script refactoring in these steps: 1. Split code into few subroutines with clear boundaries between them, or split a large script into multiple simpler scripts. 2. Add an error handler with transparent message to every line of code. 3. Add command line options to override hard-coded things, to be able to test things in isolation. 4. Write documentation (man-page) for script, for future self. 5. Write test cases. 6. Refactor code, following best practices. [0]: http://vlisivka.github.io/bash-modules/ http://vlisivka.github.io/bash-modules/ [1]: https://github.com/vlisivka/bash-modules https://github.com/vlisivka/bash-modules