Bash Variables: To quote, or not to quote...

There's one really big one you missed:

If you need the shell to treat each 'word' of your variable as separate arguments for a command, you need to not quote the variable when expanding it.

This also happens to explain the behavior surrounding whitespace:

ITEMS="foo   bar"

# This passes two arguments to `echo`, 'foo' and 'bar'
echo $ITEMS

# This passes one argument to `echo`, 'foo   bar'
echo "$ITEMS"

This is also one of the big reasons that you almost always see variables quoted when doing expansion for conditionals, and almost never see them quoted for expansion as part of a for loop. The first case (conditionals) almost always wants the contents of the variable as a single argument, while the second almost always wants each item to be a separate argument.

My opinion, you should always quote. And only exclude quotes in the "special" scenarios mentioned. Not the other way around. In my experience, if you are always asking the question "do I need to add quotes here", and only add them when you think yes, down the road you'll find out you should have, especially when someone not you on Windows or macos uses your script (they love spaces in filenames). Just get into the habit. It makes safer code. (I can't think of an easy example without eval offhand)

x="ok; ls /"
eval echo ${x}

Now you tried to be safe with the eval by adding the echo but now you have an arbitrary execution by accident. If you just got in in the habit of always using the quotes, then you would be better off

eval 'echo "${x}"'
eval "echo '${x}'"
# Both work the same, slightly different expansion order

Going back to the case of echo $NAME, how can I say "I want to explicitly support wildcard/home dir expansion and still use quotes?"

NAME="Jimmy McBride *"
NAMES=(${NAME})
echo "${NAMES[@]}"
Jimmy McBride bin calc Desktop Documents Downloads Games indicator-bulletin Music Pictures Postman Public Templates Videos

Now the code clearly show you mean to expand NAME, and you can use the array NAMES with quotes still.

As a side note, on the subject of "to curly or not to curly", I say always curly

x=100
echo $x2
echo "${x}2"

Instead of discovering you need to add {}, if you always add them, your script will just work.

I'll end with one of my favorite bashisms.

REAL_CWD="$(cd "$(dirname "${BASH_SOURCE[0]}")"; pwd)"

A sane person would say of course my directory doesn't have spaces in it. A windows person would say of course my folder has spaces in it.

Update:

I should add, the exception that is the rule is [[]]. While you should always use quotes in [] statements, you should probably never use them in [[]] statements, as they are more advanced, and don't need the quotes. In face, the quotes are literal, and can give you the wrong answer.

In the words of Ellen Ripley:

I say we take off and quote every variable in the Bash script. It’s the only way to be sure.

You forgot one more. When quoting, the value is considered a string. Otherwise it depends on the contents.

This is important for comparison operators as the comparison operators are different for integers (-eq, -gt, -lt, ...) and for strings (==, !=).

So quoting in a comparison makes it less error prone as you know you have a string and can use == to compare.

I mean... When it's a variable that kind of implies that we shouldn't make assumptions about it's contents. You know, because it's variable.