I am torn: On the one hand, the idea of having try/catch in a shell is interesting.
On the other hand, both the motivation and the effort seem out of place, out of whack: The criticism is that bash continues after errors and the examples used HAVE NO ERROR CHECKING!
Sorry for shouting, but this just boggles my mind. Someone is writing an entirely new language, with the intent of compatibility with another language, a significant effort, just because they don't want to
# dumb sample code that fails with spaces, etc.,
# just to get the point across....
handleCpError () {
errRc=$?
source=$1; target=$2
...
}
...
cp $file1 $file2 || handleCpError $file1 $file2
???
Yes, this is a contrived example, but the whole argument in favour of newShellWithTryCatch seems contrived: shell scripting is programming; good programming requires foreseeing and handling errors; don't blame the shell if it doesn't die when you think it should if you are too lazy to understand and handle potential errors.
I am working on another one, Next Generation Shell. We agree on the problem, including that error handling in bash is subpar.
> good programming requires foreseeing and handling errors
I have many small scripts that don't care about errors. Continuing execution in presence of errors is definitely not desirable in these instances, termination is. Ignoring errors is the wrong default for a language, I completely agree with Andy (the author) here. That's why bash has "set -euo pipefail" afterthought. Unfortunately it can't be made the default because of compatibility. Additionally, it has its own quirks.
In general, when judging decades old technologies, I do this check: if somebody was inventing the thing today, what would be the reaction? For bash, many choices made then would be unacceptable today. We know better now. Error handling is one of these choices.
Another related not stellar thing is the exit code of a Unix process. It was supposed to be enough to convey the status of a program. Non-zero is not always an error (think "test" or "grep"), making generic error handling not possible.
3 comments
[ 3.0 ms ] story [ 10.2 ms ] threadOn the other hand, both the motivation and the effort seem out of place, out of whack: The criticism is that bash continues after errors and the examples used HAVE NO ERROR CHECKING!
Sorry for shouting, but this just boggles my mind. Someone is writing an entirely new language, with the intent of compatibility with another language, a significant effort, just because they don't want to
???Yes, this is a contrived example, but the whole argument in favour of newShellWithTryCatch seems contrived: shell scripting is programming; good programming requires foreseeing and handling errors; don't blame the shell if it doesn't die when you think it should if you are too lazy to understand and handle potential errors.
</sermon>
https://www.oilshell.org/blog/2022/05/release-0.10.0.html#la...
And the one after on compatibility:
https://www.oilshell.org/blog/2022/05/release-0.10.0.html#ba...
I am working on another one, Next Generation Shell. We agree on the problem, including that error handling in bash is subpar.
> good programming requires foreseeing and handling errors
I have many small scripts that don't care about errors. Continuing execution in presence of errors is definitely not desirable in these instances, termination is. Ignoring errors is the wrong default for a language, I completely agree with Andy (the author) here. That's why bash has "set -euo pipefail" afterthought. Unfortunately it can't be made the default because of compatibility. Additionally, it has its own quirks.
In general, when judging decades old technologies, I do this check: if somebody was inventing the thing today, what would be the reaction? For bash, many choices made then would be unacceptable today. We know better now. Error handling is one of these choices.
Another related not stellar thing is the exit code of a Unix process. It was supposed to be enough to convey the status of a program. Non-zero is not always an error (think "test" or "grep"), making generic error handling not possible.
These are the decisions that we are paying for.