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 command assigns the value of fred to the name parameter. The second line of command 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, 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 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 command 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 filename 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 of 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 with 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 effect 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, we could potentially be deleting incorrect files if any of the names could be resolved accidentally. However, 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 command example:
$ rm "my file"
I certainly hope that these examples demonstrate the need for care when expanding parameters and make you aware of the pitfalls.