I use "set -Eeuo pipefail" in pretty much all bash scripts.
(and often -x as well)
Makes things much saner.
This post is a better introduction than the submission: https://vaneyckt.io/posts/safer_bash_scripts_with_set_euxo_p...
Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
51–60 of 114 posts
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#52In your bash shell, type:
set -e
let 1
let 0
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#53One of the reasons I created Next Generation Shell. It has exceptions. So "if $(grep ...)" works correctly as opposed to bash. grep exit codes: 0 - found, 1 - not found, 2 - error. bash can not handle this correctly in if. There are just two branches for 3 exit codes. NGS has two branches and exception that can be thrown. Yep, every single "if grep ..." in bash is a bomb.
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#54All set -e does is halt further execution of your script if any line exits above 0. There is really nothing bash can do about this. It can't perform a psychological evaluation on why a program is not giving the expected output. And most of the time, when something fails, if it were made by a less than serious programmer (like myself) they don't bother to exit on error correctly with a code above zero. But if you are…
The `let ++` example is pretty damning. I find Bash to be a poor and outdated shell that we’re stuck with for now. Its design is the best argument against LSD I know, it came out of the hippie drug days, and Bash reflects that with its madness.
> The `let ++` example is pretty damning.
Seems kind of logical, the following c code behaves the same way.
#include
int test(void) {
int i=0;
return i++;
}
void main(void) {
printf("i = %d\n", test());
}
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#55 set -euo pipefail
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#56I can highly recommend using Shellcheck [0] when writing Bash, it also has extensions for VS Code and other IDE's. It makes writing Bash much easier.
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#57I use "set -Eeuo pipefail" in pretty much all bash scripts. (and often -x as well) Makes things much saner. This post is a better introduction than the submission: https://vaneyckt.io/posts/safer_bash_scripts_with_set_euxo_p...
Thanks! I'm not doing a lot of bash scripting, so there's always something weird happening.
`set -Eeuxo pipefail` will be my new default.
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#58In the 2000s, I was running extensive sets of simulations and data reduction scripts for a scientific experiment, and I was heavy relying on scripts to run the programs, collect the results, and distribute them over several servers. At first I developed those scripts using bash, but I needed to do math and complex iterations over file names and different parameter files, and I continuously stumbled upon weird behavio…
> However, while writing this post I've just discovered that somebody has revived the project and enabled 64-bit compilation [3].
That is excellent news, if it comes to anything. At present it looks like it's still dependent on the 32-bit Scheme48. Is there a roadmap for this project?
> Nowadays I use Python for complex scripts, but it's not the same as a language with native support for redirection and pipes!
Note that Guile has support for both these. But it doesn't have the shell-tool minilanguages in it that scsh does, like the one for awk.
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#59Shell scripts can be thought like C++. They can be sanely managed only if one adopts a strict subset of functionalities.
The page is probably oriented at situations where one needs to support any version of bash and any obscure/inadvisable functionality (mind that there are still devs that mix sh and bash syntax in the same script), which is very inconvenient and error prone, so manual error handling may make sense.
While there is always something insane behind the corner in Bash, with a restricted subdomain (e.g. bash 4.2+, strict shell options, and shellcheck) it's possible to progressively write reasonably solid shell scripts.
The document conclusion is somewhat biased. "to handle errors properly" implies that `-e` in inherently unreliable, which not fair - strict shell options do remove certain classes of errors, which doesn't hurt.
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#60Short answer: because it's Bash. No syntax or language construct will do what you expected.
Sometimes it also depends on the specific version, like when you need to deal with empty arrays - https://stackoverflow.com/questions/7577052/bash-empty-array...
The answers there are just a few of the many great examples of why bash is best avoided in almost all cases.