Having established that variables are a type of parameter, we should always keep this in mind, especially, when reading manuals and HOWTOs. Often the documentation refers to parameters and in doing so they include variables, as well as, the bash special parameters, such as $1 and so on. In keeping with this, we will look at why it is advisable to quote the parameters when we use them on the command line or within scripts. Learning this now can save us a lot of pain and heartache later, especially, when we start looking at loops.

First, the correct term that we should use for reading the value of variables is parameter expansion. To you and me this is reading a variable, but to bash this would be too simple. The assignment of a correct name, such as parameter expansion reduces any ambiguity to its meaning but adds complexity at the same time. In the following example, the first line of code assigns the value of fred to the name parameter. The second line of code uses parameter expansion to print the stored value from memory. The $ symbol is used to allow the expansion of the parameter:

$ name=fred
$ echo "The value is: $name"

In the example, we have used the double quotes to allow echo to print the single string as we have used spaces. Without the use of quotes, the echo might have seen this as multiple arguments. The space being the default field separator in most shells including bash. Often, when we do not think to use the quotes, we do not see the spaces directly. Consider the following extract of command-line code that we made use of earlier:

$ FILE=/etc/hosts
$ [ -f $FILE -a -r $FILE ] && cat $FILE

Even though this worked, we may have been a little fortunate, especially, if we were populating the FILE parameter from a list of files that we had not created ourselves. It is quite conceivable that a file can have spaces within its name. Let's now replay this code using a different file. Consider the following command:

$ FILE="my file"
$ [ -f $FILE -a -r $FILE ] && cat $FILE

Even though structurally there has been no change to the code, it now fails. This is because we are providing too many arguments to the [ command. The failing result will be the same even if we use the test command.

Even though we have correctly quoted the assignment of the file name to the parameter FILE, we have NOT protected the spaces when the parameter is expanded. We can see the code failing, as it is captured in the following screenshot:

We can see that this will not be ready for our scripts. Alas, what we once thought as robust, is now in tatters and like the Titanic, our code has sunk.

However, a simple solution is to revert to quoting parameter expansion unless, specifically, not desired. We can make this ship unsinkable by a simple edit to the code:

$ FILE="my file"
$ [ -f "$FILE" -a -r "$FILE" ] && cat "$FILE"

We can now proudly stand on the White Star Line dock, as we see the Titanic II get launched in the following code example, which is captured in the following screenshot:

It is truly amazing and sometimes just a little unbelievable what affect these tiny quotes can have. We should never ignore the quotes when expanding variables. To ensure that we drill home this point, we can highlight this phenomenon in another even simpler example. Let's take the scenario where we now just want to remove the file. In the first example we do not use quotes:

$ rm $FILE

This code will produce failures as the parameter expansion will lead to the following perceived command:

$ rm my file

The code will fail because it is unable to find the my file or the file file. Even worse, potentially, we could be deleting incorrect files if any of the names could be resolved accidently.

Whereas quoting the parameter expansion will save the day, as we see in the second example:

$ rm "$FILE"

This is correctly expanded to the desired command that we illustrate in the following code example:

$ rm "my file"

I certainly hope that these examples demonstrate the need for care when expanding parameters and you are aware of the pit-falls.