Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

mywiki.wooledge.org

Post reply on HN
Print view View original

41–50 of 114 posts

Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

#41

Post by dataflow »

Ferret7446 wrote: post #40
dataflow wrote: post #18

Earlier quoted context omitted.

$ if false; then :; else (if [ $? -eq 0 ]; then echo msg; fi); fi $ if ! false; then (if [ $? -eq 0 ]; then echo msg; fi); else :; fi msg

Your original claim is disingenuous. Of course cond = false if cond; then x; else (if cond; then echo msg); fi does not do the same thing as cond = true if cond; then (if cond; then echo msg); else x; fi Bash is not somehow strange in this regard.

There's neither anything disingenuous about my claim. Bash's behavior is quite unique and unexpected to most people in the examples I showed. And I don't appreciate the attack.

Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

#42

Post by adrian_b »

ziotom78 wrote: post #32

In 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…

I had a very similar experience with using scsh for shell scripts instead of bash and it was great and far more convenient than using Python or any other language with poor support for the shell style of command execution.

I have also been forced to revert to bash later so it is good to know that there might be an update for it.

Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

#43

Post by anderskaseorg »

strken wrote: post #9

You don't have to be hyper-aware of false positives with "set -euo pipefail". False positives bring themselves to your attention during testing, while false negatives don't announce themselves at all. It's almost always preferable for your code to incorrectly fail and force you to stick "|| true" on the end, than to incorrectly succeed and let you miss the bug.

There are false negatives, such as the one mentioned in the post after “A particularly dangerous pitfall with set -e is combining functions with conditionals.”

Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

#44

Post by olau »

ziotom78 wrote: post #32

In 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…

> Nowadays I use Python for complex scripts, but it's not the same as a language with native support for redirection and pipes!

While this is no doubt right, I think you could build a little abstraction that simplified piping syntax considerable. The subprocess module is not terribly convenient, although it has gotten less confusing over the years.

Python does have operator overloading, so you could even make it fancy.

Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

#45

Post by yread »

kazinator wrote: post #7

Mainly, the reason why Bash's "set -e" doesn't do what you expected is this. set -e comes from the POSIX shell language, descended from the Bourne Shell. The examples you're using use obscure Bash features. For instance let turns an arithmetic result into a termination status, where 0 is fail (opposite to the POSIX convention and all). set -e works to the extent that your commands have a sane termination status, whic…

TFA talks about pipefail and how it sometimes fails when command writes too much.

Is read(1) an obscure feature now?

Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

#47

Post by aidenn0 »

maegul wrote: post #37
chubot wrote: post #33

All of these problems are fixed in OSH. It runs your bash scripts but you can also opt into correct error handling. The simple invariant is that it doesn't lose an exit code, and non-zero is fatal by default. See https://www.oilshell.org/release/latest/doc/error-handling.h... Oil 0.10.0 - Can Unix Shell Error Handling Be Fixed Once and For All? https://www.oilshell.org/blog/2022/05/release-0.10.0.html This took quite…

Never used OilShell (OSH) before, but this opening line on their home page struck me: > … and it's a new language for Python and JavaScript users who avoid shell! Why not work towards using python/JavaScript as shell languages? There was a HN thread a few days ago on Xonsh, the main python attempt at this which looks nice to me, which naturally got a lot of anti-anti-bash energy. But if we want better shell ergonomic…

These questions are mostly addressed here:

https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#i...

Note that osh is (really very nearly[1]) bash compatible by default, but you can opt in to incompatible parts. This lets you convert a large body of shell code gradually.

1: I think the only incompatibility is that in osh you can't index into associative arrays with unquoted words. IIRC this was to make parsing of osh decidable.

Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

#48

Post by iso1631 »

ziotom78 wrote: post #32

In 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…

Whenever I need a quick script I use bash. If that script goes beyond 20 lines or has anything but the simplest `if` or `&&`, I've learned time and time again that I should rewrite it (python for example)

Re: Why doesn't Bash’s ‘set -e’ do what I expected? (2021)

#49

Post by thayne »

powersnail wrote: post #31
thayne wrote: post #24

Earlier quoted context omitted.

Would you find it less surprising if the let command behaved differently than most other commands, and didn't stop the program if it returned a non-zero exit code? Because, this example works exactly the way I would expect. The next one (using the double parentheses syntax) is more questionable, and I could see it going either way, and would either look it up in the manual, or put an `|| true` after it to be safe. Th…

Not your parent commenter. I'd expect let command not to return a numeric value at all, since bash uses the returned numeric value to indicate success/failure. But that admittedly doesn't have anything to do with the design of "set -e".

let doesn't return the numeric value of the expression as an exit code:

> If the last ARG evaluates to 0, let returns 1; let returns 0 otherwise.

Which allows you to do things like:

    while let --i; do some command; done
or

    if let x > 4; then some command; fi
Post reply on HN