3 ms·

> some other people disagree and say you should never use `set -e` outside of development I'm really interested. What are their arguments? And how do they hand

> some other people disagree and say you should never use `set -e` outside of development I'm really interested. What are their arguments? And how do they handle errors?

bombcar 5y ago
See https://mywiki.wooledge.org/BashFAQ/105 https://mywiki.wooledge.org/BashFAQ/105 for examples of side effects. I think the idea is you use set -e during development to find where you should catch errors, but in production you may want it off to reduce strange side-effects (or explicitly check for success in the way you expect; so not that the command returned 0 but that the file it made exists and is the right length, etc).
- shikoba 5y ago
  > not that the command returned 0 but that the file it made exists and is the right length If a command returns 0 when it didn't really do its job. Shouldn't we fix the command instead of the script?
  - bombcar 5y ago
    See the link for examples of bash and posix internals that don’t necessarily operate the way you’d expect.
    - shikoba 5y ago
      They operate the way I expect. set -e fails when I don't handle the error code of a command. If my script eat it, it doesn't fail. I see no problems here.
- tedunangst 5y ago
  That seems like a really weak argument. Sometimes set -e won't catch an error, therefore it's better to let all errors slip through? "You're supposed to handle every error." Yeah, okay, set -e doesn't interfere with that.
- deathanatos 5y ago
  > but in production you may want it off to reduce strange side-effects Having -e set is to reduce strange side-effects, by having the script fail, instead of plowing headlong into the land of undefined/unexpected behavior. > See https://mywiki.wooledge.org/BashFAQ/105 https://mywiki.wooledge.org/BashFAQ/105 for examples of side effects. The `if` bit should be well-known if you're writing bash. The pipe bit is unfortunate, and is why -o pipefail is recommended, too. Or, just writing in a sane language that isn't going to page you in the middle of the night.

> some other people disagree and say you should never use `set -e` outside of development I'm really interested. What are their arguments? And how do they handle errors?

bombcar 5y ago

See https://mywiki.wooledge.org/BashFAQ/105 https://mywiki.wooledge.org/BashFAQ/105 for examples of side effects. I think the idea is you use set -e during development to find where you should catch errors, but in production you may want it off to reduce strange side-effects (or explicitly check for success in the way you expect; so not that the command returned 0 but that the file it made exists and is the right length, etc).

shikoba 5y ago
> not that the command returned 0 but that the file it made exists and is the right length If a command returns 0 when it didn't really do its job. Shouldn't we fix the command instead of the script?
- bombcar 5y ago
  See the link for examples of bash and posix internals that don’t necessarily operate the way you’d expect.
  - shikoba 5y ago
    They operate the way I expect. set -e fails when I don't handle the error code of a command. If my script eat it, it doesn't fail. I see no problems here.
tedunangst 5y ago
That seems like a really weak argument. Sometimes set -e won't catch an error, therefore it's better to let all errors slip through? "You're supposed to handle every error." Yeah, okay, set -e doesn't interfere with that.
deathanatos 5y ago
> but in production you may want it off to reduce strange side-effects Having -e set is to reduce strange side-effects, by having the script fail, instead of plowing headlong into the land of undefined/unexpected behavior. > See https://mywiki.wooledge.org/BashFAQ/105 https://mywiki.wooledge.org/BashFAQ/105 for examples of side effects. The `if` bit should be well-known if you're writing bash. The pipe bit is unfortunate, and is why -o pipefail is recommended, too. Or, just writing in a sane language that isn't going to page you in the middle of the night.