3 ms·
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 ig
by chubot 1y 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/ 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 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 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_place https://lobste.rs/s/kidktn/bash_patch_add_shopt_for_implicit...
- aidenn0 1y agoWhat 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.
- chubot 1y agoAll my scripts use pipefail, and I haven't run into problems I think `head` tends to cause SIGPIPE in practice, and that is what sigpipe_status_ok is for 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. Hm I'd be interested in an example of this The order that processes in a pipeline finish is non-deterministic, but that should NOT affect the status, with either pipefail or not. That is, the status should be deterministic ... it's possible that SIGPIPE is an exception to that, though that wouldn't affect YSH.
- xelxebar 1y agoI 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.
- chubot 1y agoYup, that is pitfall 8 here - https://oils.pub/release/latest/doc/error-handling.html#list-of-pitfalls https://oils.pub/release/latest/doc/error-handling.html#list... I think I got that from the Wooledge Wiki Explicit error handling seems fine in theory, and of course you can use that style with OSH if you want But in practice, set -e seems more common. For example, Alpine Linux abuild is a big production shell script, and they gradually switched to set -e (really, you're damned if you do, and damned if you don't, so that is a big reason YSH exists)