▲ | chubot 2 days ago | |
I use essentially this, but I think this post is over 10 years old (needs a date), and it's now INCOMPLETE. bash introduced an option to respect rather than ignore errors within command sub processes years ago. So if you want to be safer, do something like:
That works as-is in OSH, which is part of https://oils.pub/(edit: the last time this came up was a year ago, and here's a more concrete example - https://lobste.rs/s/1wohaz/posix_2024_changes#c_9oo1av ) --- But that's STILL incomplete because POSIX mandates that errors be LOST. That is, it mandates broken error handling. For example, there what I call the "if myfunc" pitfall
But even if you fix that, it's still not enough.--- I describe all the problems in this doc, e.g. waiting for process subs: YSH Fixes Shell's Error Handling (errexit) - https://oils.pub/release/latest/doc/error-handling.html Summary: YSH fixes all shell error handling issues. This was surprisingly hard and required many iterations, but it has stood up to scrutiny. For contrast, here is a recent attempt at fixing bash, which is also incomplete, and I argue is a horrible language design: https://lobste.rs/s/kidktn/bash_patch_add_shopt_for_implicit... | ||
▲ | xelxebar 2 days ago | parent | next [-] | |
I kind of feel like set -o errexit (i.e. set -e) provides enough unexpected semantics that explicit error handling makes more sense. One thing that often trips people up is this:
but
modulo some version differences. | ||
▲ | aidenn0 2 days ago | parent | prev [-] | |
What are your thoughts on pipefail in bash? I know ysh (and maybe osh too?) are smart about a -13 result from a pipe, but I stopped using pipefail since the return value can be based on a race, causing things to randomly not work at some point in the future. [edit] Per the link you posted osh treats a -13 result as success with sigpipe_status_ok, but I'm still interested in your thoughts on if pipefail is better or worse to recommend as "always on" for bash. |