Annoyingly, when a process is terminated by an unhandled signal (say, SIGTERM), it is treated as if it exited with a nonzero exit code. This can make it tricky to use non-builtin commands as conditions in "if" statements, since there's always the potential edge case where the "if" block is skipped because of a signal that the condition received.
Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
11–20 of 114 posts
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#12All 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.
A lot of the sins of shell are from it's primary role as an interactive interface to the computer. it's use as a scripting language was a nice secondary goal.
On the one hand it is nice to have your interactive interface and your scripts be the same language. on the other it is a bit horrifying the way all those convenient interactive features make your programs so prone to failure.
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#13All 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…
Bash is the only language I know where
if cond; then x; else y; fi
if ! cond; then y; else x; fi
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#14All 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…
how long until there's an AI advanced enough to give psychological evaluation to other programs?
/joke
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#15All 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…
Bash is the only language I know where if cond; then x; else y; fi does not do the same thing as if ! cond; then y; else x; fi despite the the absence of any operator overloading.
Curious on this one, do you have an example showing it not working as expected?
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#16I'm not sure what this person did expect. That bash magically parsed the output and memory of running programs, and read the user's thoughts, to determine if the state of the program indicates a condition that the user would consider an error?
set -e does exactly what you'd expect, arguably, with the exception of subshells and conditions.
And those rules are extremely simple to learn too. If you understand when a statement which might be composed of other statements would have an error, you can predict what set -e will do
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#17[deleted]
Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#18Earlier quoted context omitted.
Bash is the only language I know where if cond; then x; else y; fi does not do the same thing as if ! cond; then y; else x; fi despite the the absence of any operator overloading.
Curious on this one, do you have an example showing it not working as expected?
$ if false; then :; else (if [ $? -eq 0 ]; then echo msg; fi); fi
$ if ! false; then (if [ $? -eq 0 ]; then echo msg; fi); else :; fi
msgRe: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#19I'm not sure what this person did expect. That bash magically parsed the output and memory of running programs, and read the user's thoughts, to determine if the state of the program indicates a condition that the user would consider an error? set -e does exactly what you'd expect, arguably, with the exception of subshells and conditions. And those rules are extremely simple to learn too. If you understand when a sta…
Did you look at the examples? The first examples has me completely puzzled.
#!/usr/bin/env bash
set -e
i=0
let i++
echo "i is $i"Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)
#20If you modify your PS1 to include $? It makes writing shell scripts that rely on exit codes a lot easier. It should be the default in my opinion.
Build scripts that fail and return 0 are my nemesis.