[seorphates]

Ok, "garbage" may have been harsh but how about a fun example? Try this with and without -e

  #!/usr/bin/env bash

  bell=`tput bel`
  tock='Blastoff!'

  do_ring()
  {
    if [ "$1" ]; then # true
      echo -n $bell; sleep 0.1
      echo -n $bell; sleep 0.1
      echo -n $bell; sleep 0.1
      echo $tock
    else
      echo -n $bell; sleep 0.1
    fi
  }

  i=3
  while [ "$i" -ge "0" ];
  do
    if [ $i = 0 ]; then
      sleep 0.5
      echo ok
    else
      echo $i $bell
      sleep 0.5
    fi
    i=`expr $i - 1`
  done

  do_ring $1 # do something different if arg
  sleep 1
  echo neat.
  

Semantic qualities aside there is something here that breaks with -e and if you're used to using -e by default you might be baffled and think shell sucks, for example.

[clarry]

That's why nobody uses expr for arithmetic. But yes, it is annoying that -e breaks some habits that work fine without it.

[seorphates]

I can appreciate the quip, especially given my curmundgeonly entry. But the point remains. The shell needs to be able to call any command on the system reliably. Even aged old counting methods. At no point in that loop would the expr subprocess return other than zero. Try to break out of that loop with that bash switch.

One should not rely on these magics, the ones that alter runtime behaviors, without truly understanding what you're after and what you're writing. Or mostly understand. They're fine and good if you have narrow routines with a very strict focus - "I'm in, I'm out, bang."

The best switches available to the shell without a bunch of feature and package and library this or that bloat are exactly

  -x
  -n

That's all that you need to ensure that your scripting is what you need it to be. Introduce the magic after you've written the thing. When it's ready and it passes your tests then test it again.

Every single utility and package on that system is at your fingertips. Demand accuracy. I do.