Most bash scripts are very brittle because error handling is an afterthought. In this blogpost you'll learn about the easiest ways to gracefully catch and handle errors. Best practices and common pitfalls.
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.
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.
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.
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.
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.
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.