3 ms·

They have inherited the second biggest mistake of shellscripts; Requiring the user to manually check $? after each command. No thanks. Anything that doesn't ha

• nomilk 2y ago
  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 https://stackoverflow.com/a/54132729/5783745
• tasuki 2y ago
  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!)
• stouset 2y ago
  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.
• latexr 2y ago
  > 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 https://www.shellcheck.net/wiki/SC2181
  • jerska 2y ago
    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.
    • latexr 2y ago
      > 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”?
• oopsallmagic 2y ago
  How is it supposed to know how you want your errors handled by default? Handling errors is the programmer's job.
  • Too 2y ago
    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.