3 ms·

I mostly just have a problem with the default behavior of ignoring errors and continuing (yes I know it can be overridden). This coupled with the fact that you'

I mostly just have a problem with the default behavior of ignoring errors and continuing (yes I know it can be overridden). This coupled with the fact that you'll be working almost exclusively with strings, and all the quoting and escaping rules (which can be a huge pain themselves), can easily lead to bugs like this one https://github.com/ValveSoftware/steam-for-linux/issues/3671 https://github.com/ValveSoftware/steam-for-linux/issues/3671 . I have written some bash scripts myself, but none that were longer than maybe 10-20 lines. Above that, I usually reach for other tools.

barrkel 11y ago
I've written some in the 200-300 line range, that took 500+ lines of Ruby to replace. Ruby was less efficient in wall-clock time, but easier to scale up in features. It required using a database for storage rather than line-oriented text files (the problem set was too large to fit in-memory as Ruby objects at least) - a source of performance loss, as I went with sqlite to keep things self-contained. I could have coded in a pipe / batch oriented way like bash, but then I wouldn't have gained any ease of feature implementation. If you can express a problem as a set of filters and pipes, don't need to fork too much, and have efficient executables to run each stage of the pipe, bash can be hard to beat without breaking out a real programming language with threading support. That's because bash isn't doing the heavy lifting, just doing process orchestration - something it does better than any scripting language I've used. <() in particular is tedious to do in most non-shells (and many alleged shells).
lisivka 11y ago
Use "set -ue -o pipefail" at beginning of the shell script for "strict mode". Use "bash-modules" library, which is designed for strict mode. Always quote variables unless you really want them to be parsed by bash.

barrkel 11y ago

I've written some in the 200-300 line range, that took 500+ lines of Ruby to replace. Ruby was less efficient in wall-clock time, but easier to scale up in features. It required using a database for storage rather than line-oriented text files (the problem set was too large to fit in-memory as Ruby objects at least) - a source of performance loss, as I went with sqlite to keep things self-contained. I could have coded in a pipe / batch oriented way like bash, but then I wouldn't have gained any ease of feature implementation. If you can express a problem as a set of filters and pipes, don't need to fork too much, and have efficient executables to run each stage of the pipe, bash can be hard to beat without breaking out a real programming language with threading support. That's because bash isn't doing the heavy lifting, just doing process orchestration - something it does better than any scripting language I've used. <() in particular is tedious to do in most non-shells (and many alleged shells).

lisivka 11y ago

Use "set -ue -o pipefail" at beginning of the shell script for "strict mode". Use "bash-modules" library, which is designed for strict mode. Always quote variables unless you really want them to be parsed by bash.