[fivea]

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

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]

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/

[1]: https://github.com/vlisivka/bash-modules