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.
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.