4 ms·

Reading the associated issue (https://github.com/fish-shell/fish-shell/issues/510 https://github.com/fish-shell/fish-shell/issues/510) about the lack of "set -e

by wzdd 2y ago

Reading the associated issue (https://github.com/fish-shell/fish-shell/issues/510 https://github.com/fish-shell/fish-shell/issues/510) about the lack of "set -e" was interesting as it highlighted how weird Bash, and shell scripting in general, is from a programming language perspective. Imagine programming in any other environment where every function you call could either succeed or fail catastrophically. There's some talk about adding exception handling to Fish, but maybe the sensible thing to do is to have a mode where Fish ensures that you've dealt with each possible error before moving on. Which is what you would do anyway if you were invoking external programs from a non-shell language (like Python's subprocess.check_call). In any case the discussion in that issue made a convincing (to me) argument that if you're doing the sort of scripting for which "set -e" makes sense, which is most of it, you should be using Bash. That doesn't mean you need to use Bash interactively though, as others have pointed out.

pcthrowaway 2y ago
> Imagine programming in any other environment where every function you call could either succeed or fail catastrophically Laughs in client-side JS.
- pavlov 2y ago
  Hmm? It’s not like a JavaScript exception crashes the entire browser tab. Client-side JS is event-driven. An unhandled exception stops processing for that event, but doesn’t block other events.
izietto 2y ago
But, scripting languages are not programming languages, scripting languages are made to run commands, and by default a script should halt if a command fails, at least in the CLI execution context. The problem is, scripting languages mix programming context and scripting context, so a condition written in the script shouldn't be treated as a CLI exit status. Anyway, I don't use fish for scripts just for the lack of exit on command error. That's essential while scripting.
masklinn 2y ago
> Imagine programming in any other environment where every function you call could either succeed or fail catastrophically There's not much to imagine since that's pretty much every other language? Sure you can recover with error handlers (sometimes[0]), but by default all of them will hard abort in case of exceptions. In our modern language landscape shells are very much the odd ones, where errors are completely silent by default and the thing just carries on oblivious that the world around it might be crumbling completely. [0]: https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-with-panic.html#unwinding-the-stack-or-aborting-in-response-to-a-panic https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-...

by wzdd 2y ago

pcthrowaway 2y ago

> Imagine programming in any other environment where every function you call could either succeed or fail catastrophically Laughs in client-side JS.

pavlov 2y ago
Hmm? It’s not like a JavaScript exception crashes the entire browser tab. Client-side JS is event-driven. An unhandled exception stops processing for that event, but doesn’t block other events.

izietto 2y ago

But, scripting languages are not programming languages, scripting languages are made to run commands, and by default a script should halt if a command fails, at least in the CLI execution context. The problem is, scripting languages mix programming context and scripting context, so a condition written in the script shouldn't be treated as a CLI exit status. Anyway, I don't use fish for scripts just for the lack of exit on command error. That's essential while scripting.

masklinn 2y ago

> Imagine programming in any other environment where every function you call could either succeed or fail catastrophically There's not much to imagine since that's pretty much every other language? Sure you can recover with error handlers (sometimes[0]), but by default all of them will hard abort in case of exceptions. In our modern language landscape shells are very much the odd ones, where errors are completely silent by default and the thing just carries on oblivious that the world around it might be crumbling completely. [0]: https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-with-panic.html#unwinding-the-stack-or-aborting-in-response-to-a-panic https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-...