Remix.run Logo
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:

    #!/bin/bash
    set -euo pipefail
    shopt -s inherit_errexit 
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

    set -e

    my-deploy-func  # errors respected

    if ! my-deploy-func; then   # errors lost
      echo failed
    fi
    my-deploy-func || echo fail  # errors lost
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:

    set -e
    [ -f nonexistent ] && do_something
    echo 'this line runs'
but

    set -e
    f(){ [ -f nonexistent ] && do_something; }
    f
    echo 'This line does not run'
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.