[bombcar]

See 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).

[deathanatos]

> 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 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.

[shikoba]

> 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]

See the link for examples of bash and posix internals that don’t necessarily operate the way you’d expect.

[shikoba]

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]

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.