this post was submitted on 11 Feb 2026
61 points (98.4% liked)

Programming

25463 readers
322 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
UlrikHD@programming.dev
bugsmith@programming.dev
Spyro@programming.dev
61
Error handling in bash (notifox.com)
submitted 11 hours ago by BlackEco@lemmy.blackeco.com to c/programming@programming.dev
17 comments fedilink hide all child comments
top 17 comments
sorted by: hot top controversial new old
[–] Ephera@lemmy.ml 9 points 6 hours ago (2 children)

What I always find frustrating about that, is that even a colleague with much more Bash experience than me, will ask me what those options are, if I slap a set -euo pipefail or similar into there.

I guess, I could prepare a snippet like in the article with proper comments instead:

set -e # exit on error
set -u # exit on unset variable
set -o pipefail # exit on errors in pipes

Maybe with the whole trapping thing, too.

But yeah, will have to remember to use that. Most Bash scripts start out as just quickly trying something out, so it's easy to forget setting the proper options...

[–] SlykeThePhoxenix@programming.dev 2 points 2 hours ago

I only use -eu. -o sometimes breaks

[–] vext01 2 points 2 hours ago

Problem is, -o pipefail isn't portable.

[–] FizzyOrange@programming.dev -1 points 2 hours ago

If you think you need this you're doing it wrong. Nobody should be writing bash scripts more than a few lines long. Use a more sane language. Deno is pretty nice for scripting.

[–] thingsiplay@lemmy.ml 9 points 10 hours ago (2 children)

As you'll learn later in this blogpost, there are some footguns and caveats you'll need to keep in mind when using -e.

I am so glad this article is not following blind recommendations, as lot of people usually do. It's better to handle the error, instead closing the script that caused the error. I think the option -e should be avoided by default, unless there is a really good reason to use it.

[–] thenextguy@lemmy.world 7 points 9 hours ago (2 children)

The point of using -e is that it forces you to handle the error, or even be aware that there is one.

[–] IanTwenty@piefed.social 1 points 4 hours ago

Errors in command substitution e.g. $(cat file) are ignored by 'set -e', one example of its confusing nature. It does not force you to all handle errors, just some errors and which ones depends on the code you write.

https://mywiki.wooledge.org/BashPitfalls#set_-euo_pipefail

[–] thingsiplay@lemmy.ml 5 points 9 hours ago (2 children)

In my experience this option is too risky. Making simple changes to the script without scientifically proofing and testing it works under all cases becomes impossible (depending on how complex the script and task itself is). It has a bit of the energy of "well you have to make no errors in C, then you can write good code and it never fails".

This option is good if the script MUST fail under any circumstances, if any error return of a program occurs. Which is usually not the case for most scripts. It's also useful in testing when debugging or when developing. Also useful if you purposefully enable and disable the option on the fly for sensitive segments of the script. I do not like this option as a default.

[–] Feyd@programming.dev 4 points 5 hours ago (1 children)

Ehhh I don't think I've used bash outside of random stuff on my machine in years except in CI pipelines and wanting them to stop and fail the pipeline the second anything goes wrong is exactly what I want.

[–] thingsiplay@lemmy.ml 2 points 5 hours ago

I do not want to think about every possible error that can happen. I do not want to study every program I call to look for any possible errors. Only errors that are important to my task.

As I said, there are reasons to use this option when the script MUST fail on error.And its helpful for creating the script. I just don't like generalizations to always enable this option.

[–] Ephera@lemmy.ml 6 points 6 hours ago (2 children)

I don't have the Bash experience to argue against that, but from a general programming experience, I want things to crash as loudly as possible when anything unexpected happens. Otherwise, you might never spot it failing.

Well, and nevermind that it could genuinely break things, if an intermediate step fails, but it continues running.

[–] eager_eagle@lemmy.world 1 points 1 hour ago

Exactly, if an unhandled error happened I want my program to terminate. -e is a better default.

[–] thingsiplay@lemmy.ml 3 points 6 hours ago* (last edited 6 hours ago) (2 children)

Bash and the commandline are designed to work after an error. I don't want it to fail after an error. It depends on the error though, and how critical it is. And this option makes no distinction. There are lot of commands where a fail is part of normal execution. As I said before, this option can be helpful when developing, but I do not want it in production. Often "silent" fails are a good thing (but as said, it depends on the type). The entire language is designed to sometimes fail and keep working as intended.

You really can't compare Bash to a normal programming language, because the language is contained and developed in itself. While Bash relies on random and unrelated applications. That's why I do not like comparisons like that.

Edit: I do do not want to exit the script on random error codes, but maybe handle the error. With that option in place, I have to make sure an error never happens. Which is not what I want.

[–] eager_eagle@lemmy.world 2 points 1 hour ago* (last edited 1 hour ago)

Often "silent" fails are a good thing

Silent fails have caused me to waste many hours of my time trying to figure out what the fuck was happening with a simple script. I've been using -e on nearly all bash code I've written for years - with the exception of sourced ones - and wouldn't go back.

If an unhandled error happened, I want my program to crash so I can evaluate whether I need to ignore it, or actually handle it.

[–] Gobbel2000@programming.dev 1 points 1 hour ago

But you can just as well make an exception to allow errors when -e is enabled with something like command || true, or even some warning message.

I feel like, while it does occur, allowing errors like this is more unusual than stopping the script in an error, so it's good to explicitly mark this case, therefore -e is still a reasonable default in most cases.

[–] thingsiplay@lemmy.ml 4 points 10 hours ago

BTW here is an interesting discussion on Github about this topic: bash_strict_mode.md

[–] Paragone@lemmy.world 1 points 7 hours ago

EXCELLENT Article!

Now interested in Notifox, that person's pet-project, too..

( :