2 ms·

I think bash is fine as a shell and I understand why the syntax is the way it is, I'd just never use it for anything beyond a one liner or a list of commands. A

I think bash is fine as a shell and I understand why the syntax is the way it is, I'd just never use it for anything beyond a one liner or a list of commands. All my points were about its weaknesses for scripting, ie, anything that looks and acts like a program. There's basically no reason to use it that way when there are a million better programming languages that are ubiquitous and relatively small.

jolmg 8y ago
It still seems better suited when the script is mostly about running executables and passing their inputs and outputs between each other. As an example, I think `pass` was very nicely chosen to be done in bash. I don't think there would've been any benefit in doing it in a non-shell language. I also think that if a program's job is by good proportion about sourcing shell-scripts to e.g. prepare an environment for them and/or manage their execution, it's also a good idea to make that program in the same shell language. As an example of this, I think Archlinux's `makepkg` was best done in bash. On why make a program that's about sourcing shell scripts at all, the shell is the one common language all Unix-based OS users know in common, pretty much by definition, so it makes it a good candidate for things like the language of package description files. Besides the fact that software packaging of any language involves the shell, you kind of expect people that call directly on `makepkg` to also want to be able to edit these files, so making them in the language that they're most likely to know is good.