[brtknr]

Probably easier to stick to bash rather than learn a new set of commands from scratch. Also bash commands are universally available whereas this needs to be installed first which is not always that straightforward. Also python is slower at some of the examples than compiled executables.

[otikik]

“Universal” is too much of a stretch. You still get tripped by things like “that flag doesn’t exist in OSX sed” or “that option in git was only available in git > 2.8.14”

And that’s how you end up with bash scripts wrapped inside Docker images, that I have been seeing for the last couple of years.

[baq]

Suddenly xonsh from a sibling thread doesn’t sound outrageous anymore

[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