I couldn't spot any way to make something like `ls -j` (j is an illegal option) throw an exception in ruby (as opposed to simply outputting the system error message).

The closest I could find is what you suggest (checking $?), or using something like this [1], which would require changing syntax:

  system('ls -j', exception: true) 

Would be great to know if there's some easy callback or, ideally, a global setting one can make so a ruby exception is thrown if there's an error running system commands using the backtick syntax.

[1] https://stackoverflow.com/a/54132729/5783745

> They have inherited the second biggest mistake of shellscripts; Requiring the user to manually check $? after each command.

This isn’t true for Ruby nor shell scripts. In Ruby you have `system` or `Open3`. In shell scripts you:

  if my_command
  then
    on_success
  else
    on_failure
  fi

Shellcheck even warns you of that.

https://www.shellcheck.net/wiki/SC2181

You’re checking the return value of the command here. Do you wrap all calls in an if?

I believe the author was talking about set -e (often used with -o pipefail), so that any unhandled error simply exits the script.

> Do you wrap all calls in an if?

I don’t need to check the exit status of every command.

> I believe the author was talking about set -e (often used with -o pipefail), so that any unhandled error simply exits the script.

I have no idea how you could get that impression from the section I quoted.

How would setting one option once at the top of the script mean “Requiring the user to manually check $? after each command”?

It's not required to check $? after each command. It's only when calling out to the shell. How would you propose to handle that? Throw an exception on a shell command which fails?

Some would say calling out to shell is an anti pattern by itself. Others would say exceptions are an anti pattern. (Just use appropriate return type and there's no need for exceptions ever!)

This is only true for backticks, which are somewhat intended for non-serious use. If you want exceptions for subprocess failure, `system` does the trick.

There’s really no need for this kind of over-the-top response.

How is it supposed to know how you want your errors handled by default? Handling errors is the programmer's job.

There are lots of techniques to make it obvious that errors can happen and need to be handled.

1. Make it difficult to ignore that a function can return an error. This is the golang approach. Errors are part of the return values and unused return values are compiler errors.

2. Make it impossible to use parts of the return value having an error state. Rust does this with the Result sum type and pattern matching.

3. Tailor for the happy-path and throw exceptions in case there are any errors. With optional means to catch them if recovering errors is desired. This is how most other languages function.

Hiding the error status in another variable, that is super easy to overlook and that the programmer might not even know exists, then continuing despite this variable not being checked will inevitably introduce bugs allowing faulty data in your system.