2 ms·

No, it's not. Nor did the parent indicate such. set -euo pipefail should be the default so that the script exits on at least some unexpected state/command resu

• inferiorhuman 4y ago
  The problem with set -e is that you end up failing in inconsistent and non-intuitive ways. e.g. https://stackoverflow.com/questions/4072984/how-do-i-get-the-effect-and-usefulness-of-set-e-inside-a-shell-function https://stackoverflow.com/questions/4072984/how-do-i-get-the... https://serverfault.com/questions/143445/what-does-set-e-do-and-why-might-it-be-considered-dangerous https://serverfault.com/questions/143445/what-does-set-e-do-... pipefail is worse because tools like grep return non-zero for things that aren't inherently errors. Error handling in sh-like shells is archaic enough that if you're reaching for it you should strongly consider reaching for a different language.
  • 411111111111111 4y ago
    you're missintepreting what i said. I'm saying that a script which would have the potential to fail unintuitively from `set -eup pipefail` probably shouldn't be written in shell and most definitely shouldn't continue to execute once an unexpected state has occured. You're right that there are a lot of cases in which non-zero exitcodes are the expected behaviour. But if you're accepting these commands with non-zero exitcodes then you're already doing error handling by verifying the output of the commands (at least hopefully), which was the original criteria from the OP for writing the script in another language.