6 ms·

All set -e does is halt further execution of your script if any line exits above 0. There is really nothing bash can do about this. It can't perform a psycholog

• mdaniel 4y ago
  Also, error messages to stderr, please, and bonus points for not trying to emit cute ansi color codes unconditionally
  • hinkley 4y ago
    CI tools: telling you who the asshole is, since 2001.
• koala_man 4y ago
  > All set -e does is halt further execution of your script if any line exits above 0. This is the expectation, and the article is about why it's not that simple.
• stevebmark 4y ago
  The `let ++` example is pretty damning. I find Bash to be a poor and outdated shell that we’re stuck with for now. Its design is the best argument against LSD I know, it came out of the hippie drug days, and Bash reflects that with its madness.
  • somat 4y ago
    A lot of the sins of shell are from it's primary role as an interactive interface to the computer. it's use as a scripting language was a nice secondary goal. On the one hand it is nice to have your interactive interface and your scripts be the same language. on the other it is a bit horrifying the way all those convenient interactive features make your programs so prone to failure.
    • justin_oaks 4y ago
      We'd probably all be better off if our scripts weren't in the same language as used by our interactive interface. I do paste snippets of scripting (if, for, etc.) into my interactive terminal from time to time, but that's rare compared to just typing commands to run. I wouldn't mind it if all scripting in the shell had to be offloaded to a completely separate language that was less error prone and more consistent.
  • trashtester 4y ago
    > The `let ++` example is pretty damning. Seems kind of logical, the following c code behaves the same way. #include <stdio.h> int test(void) { int i=0; return i++; } void main(void) { printf("i = %d\n", test()); } 'let i++' evaluates to / returns 0 before increasing i, just like c would.
    • stevebmark 4y ago
      I don't mean what it returns, I mean that returning non-zero trips up Bash into thinking it's a non-successful error code. The fact that doing math can trip up error detection implies a fundamental design flaw of the system. Which, I mean, we're in Bash, of course it's poorly designed. I didn't know it was quite this bad though.
  • ohiovr 4y ago
    Interesting.. that might be part of why I fell in love with this ugly monster called Bash scripting.
• dataflow 4y ago
  Bash is the only language I know where if cond; then x; else y; fi does not do the same thing as if ! cond; then y; else x; fi despite the the absence of any operator overloading.
  • nikau 4y ago
    Curious on this one, do you have an example showing it not working as expected?
    • dataflow 4y ago
      $ if false; then :; else (if [ $? -eq 0 ]; then echo msg; fi); fi $ if ! false; then (if [ $? -eq 0 ]; then echo msg; fi); else :; fi msg
      • nikau 4y ago
        That's correct behavior though. You should do if ARG=false Then use $ARG not $? in the if statement.
        • dataflow 4y ago
          It's the best kind of correct, yes.
          • nikau 4y ago
            It's a pretty bizarre use case, why would you need the second if statement, you already are in logic based on the return code I can't think of an example of the if statement being confusing that isn't relying on $?
            • dataflow 4y ago
              error=0 if ! some_command; then error=$?; bar; fi echo "blah" return $error
• yellsatclouds 4y ago
  how long until there's an AI advanced enough to give psychological evaluation to other programs? /joke
  • ohiovr 4y ago
    They could sing Daisy Daisy together.