5 ms·

For robust code you should also use set -e. This changes things again. Often a process started by the shell will get the signal, too (depends of course on how

For robust code you should also use set -e. This changes things again. Often a process started by the shell will get the signal, too (depends of course on how it is sent) and exit with a non-zero return value (depends on the process of course). I believe (not at the computer right now) the handler for EXIT is called in that case. Was it so that bash can also trap ERR, but dash cannot? It's not perfectly easy to handle all possible cases, and certainly impossible in a fully portable way.

tjoff 3y ago
> For robust code you should also use set -e. Highly debatable.
- digitalsushi 3y ago
  In my enterprise environment of legacy systems with 97% reliability, our scripts often run without -e and the effect is we deliver broken stuff constantly. But people get results. They get an email that says "an unknown error occurred". This can be superior to running some tiny shell script with -e and breaking that communication. It's kind of subjective to the experience.
  - usr1106 3y ago
    Of course using set -e without an exit handler is contraproductive. We use an exit handler that reports "$0 has exited prematurely" in cases the script did not reach expected exit points.
- usr1106 3y ago
  What are the arguments to leave it out? Of course in special cases where you do explicit error handling you can disable it. But for the big mass of commands where nobody checks whether it worked.
  - npongratz 3y ago
    http://mywiki.wooledge.org/BashFAQ/105#So-called_strict_mode http://mywiki.wooledge.org/BashFAQ/105#So-called_strict_mode > The behavior of set -e is quite unpredictable. If you choose to use it, you will have to be hyper-aware of all the false positives that can cause it to trigger, and work around them by "marking" every line that's allowed to fail with something like ||true. Start there, then go back to the beginning for the extensive exposition against using set -e. FWIW, I (a random person on the internet) use set -e for most scripts I write, and despite the caveats, find set -e is generally more beneficial than troublesome. I don't think Mr. Wooledge is wrong, it's just the groove I've settled in. I do sometimes consciously avoid using set -e, when I explicitly handle errors for every single element of the script.
    - usr1106 3y ago
      The link is interesting, but more a rant than convincing not to use set -e. What would be the alternative? Handling errors yourself in every single command will for sure introduce more surprises and bugs. Of course bash is not the language to control a nuclear power plant. Even C has tons of undefined behavior. But writing all the shell scripts we use in this company without major problems in Rust would be prohibitively expensive. I do not doubt that may bash scripters shoot themselves in the foot. You need at least one reviewer that understands well how the language works. That said I prefer dash for scripting except when I really need arrays, which is rare. I have no scientific evidence, but KISS is good and bash just seems to have too many bells and whistles. And as the article mentions, bash seems to change in surprising ways between versions. I have also been bitten by that. Unfortunately dash has no set -o pipefail.

tjoff 3y ago

> For robust code you should also use set -e. Highly debatable.

digitalsushi 3y ago
In my enterprise environment of legacy systems with 97% reliability, our scripts often run without -e and the effect is we deliver broken stuff constantly. But people get results. They get an email that says "an unknown error occurred". This can be superior to running some tiny shell script with -e and breaking that communication. It's kind of subjective to the experience.
- usr1106 3y ago
  Of course using set -e without an exit handler is contraproductive. We use an exit handler that reports "$0 has exited prematurely" in cases the script did not reach expected exit points.
usr1106 3y ago
What are the arguments to leave it out? Of course in special cases where you do explicit error handling you can disable it. But for the big mass of commands where nobody checks whether it worked.
- npongratz 3y ago
  http://mywiki.wooledge.org/BashFAQ/105#So-called_strict_mode http://mywiki.wooledge.org/BashFAQ/105#So-called_strict_mode > The behavior of set -e is quite unpredictable. If you choose to use it, you will have to be hyper-aware of all the false positives that can cause it to trigger, and work around them by "marking" every line that's allowed to fail with something like ||true. Start there, then go back to the beginning for the extensive exposition against using set -e. FWIW, I (a random person on the internet) use set -e for most scripts I write, and despite the caveats, find set -e is generally more beneficial than troublesome. I don't think Mr. Wooledge is wrong, it's just the groove I've settled in. I do sometimes consciously avoid using set -e, when I explicitly handle errors for every single element of the script.
  - usr1106 3y ago
    The link is interesting, but more a rant than convincing not to use set -e. What would be the alternative? Handling errors yourself in every single command will for sure introduce more surprises and bugs. Of course bash is not the language to control a nuclear power plant. Even C has tons of undefined behavior. But writing all the shell scripts we use in this company without major problems in Rust would be prohibitively expensive. I do not doubt that may bash scripters shoot themselves in the foot. You need at least one reviewer that understands well how the language works. That said I prefer dash for scripting except when I really need arrays, which is rare. I have no scientific evidence, but KISS is good and bash just seems to have too many bells and whistles. And as the article mentions, bash seems to change in surprising ways between versions. I have also been bitten by that. Unfortunately dash has no set -o pipefail.