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

31–40 of 114 posts

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

#31

Post by powersnail »

thayne wrote: post #24
wodenokoto wrote: post #19

Earlier quoted context omitted.

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"

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".

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

#32

Post by ziotom78 »

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 behaviors and had to rely to hard-to-understand quirks like the ones explained in the article (which bit me more than once!).

After a while I stumbled upon scsh [1], which at first didn't impress me because I ran it as an interactive shell, and from this point of view it was really ugly. But then I realized that scsh was primarily meant as a way to run shell scripts, and I immediately felt in love. I had the power of a Scheme interpreter, the ability to easily use mathematical expressions (the awesomeness of Scheme's numerical tower!) and macros, and a very effective way to redirect inputs and outputs and pipe commands that was embedded in the language [2]!

In those years I used scsh a lot and developed quite complex scripts using it, it was really a godsend. Unfortunately the program got abandoned around 2006 because it was not trivial to add support for 64-bit architectures. However, while writing this post I've just discovered that somebody has revived the project and enabled 64-bit compilation [3]. I would love to see a revamp! Nowadays I use Python for complex scripts, but it's not the same as a language with native support for redirection and pipes!

[1] https://scsh.net/

[2] https://scsh.net/docu/html/man-Z-H-3.html#node_chap_2

[3] https://github.com/scheme/scsh

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

#33

Post by chubot »

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 awhile, and I became aware of more error handling gotchas than I knew about when starting the project:

e.g. it's impossible in bash to even see the error status of a process sub like diff If you have bash scripts that you don't want to rewrite, try

1) run them with OSH

2) Add shopt --set oil:upgrade at the top to get the error handling fixes.

Tell me what happens :) https://github.com/oilshell/oil

I spent a long time on that, but the post didn't get read much. I think it's because it takes a lot of bash experience to even understand what the problem is.

(rehash of https://news.ycombinator.com/item?id=33075915 which came up the other day :) )

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

#34

Post by kazinator »

interroboink wrote: post #4
gurjeet wrote: post #2

Also noteworthy, this post of mine with authoritative text from GNU docs. Read "(Un)Portable Shell Programming" https://news.ycombinator.com/item?id=31678176

Or, as Larry Wall put it, "It is easier to port a shell than a shell script."

That was no idle musing; he had in mind a reversal of the situation.

He put that into action by making a language so embroiled in its own implementation that cloning a new version would be a pointless exercise in failing to replicate the internal details of the original program. That nicely solved the problem of it being hard to port a script.

Then he made it incredibly hard to build. Cross-compiling it wasn't even a thing, and probably still isn't; we just use distro builds that have Qemu.

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

#35

Post by nikau »

dataflow wrote: post #27
nikau wrote: post #25

Earlier quoted context omitted.

It's a pretty bizarre use case, why would you need the second if statement, you already are in logic based on the return code I can't think of an example of the if statement being confusing that isn't relying on $?

error=0 if ! some_command; then error=$?; bar; fi echo "blah" return $error

Yep that's a valid scenario, if you need more granularity than just fail or success then you will have to use a different method, e.g.

Status=0

Somecommand || status=$?

Then do logic based on status

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

#36

Post by masklinn »

dataflow wrote: post #13
ohiovr wrote: post #3

All 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.

Isn’t sql an other one?

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

#37

Post by maegul »

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 ergonomics and are willing to ditch bash, why not take popular versatile and capable languages and get them shell-appropriate? It seems like a natural use case for these languages, and even the place where they could retire to peacefully in the future.

I suppose OSH is aiming at bash compatibility, but how good or viable is that really (not a rhetorical question)? Seems to me like an all or nothing thing as someone who recently ran into some bash-zsh incompatibility.

~~~

HN thread on Xonsh: https://news.ycombinator.com/item?id=33044772

Xonsh homepage: https://xon.sh/

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

#39

Post by Dylan16807 »

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…

I tried xonsh for a while but it was just so slow to chdir a good fraction of the time that I gave up. (Running under WSL2, navigating around linux and windows directories.) Also looking up the syntax was awkward and I still had to copy and paste to make editing multi-line commands be sane.

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

#40

Post by Ferret7446 »

dataflow wrote: post #18
nikau wrote: post #15

Earlier quoted context omitted.

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 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.
Post reply on HN