Excellent article. The quick summary ([1]) is particulary good.
Note that quoting variable names is a good idea for other reasons, e.g., when a variable unexpectedly ends up empty: Not quoting such a variable can lead to termination in calls to test ([ ]), e.g., because the empty variable is replace with nothing (so that test sees the next non-whitespace token instead of the expected variable value, empty or otherwise), while quoting will at least cause the shell to correctly replace the variable with an empty string.
I wonder if this can cause security issues. In particular, suppose you can create an arbitrarily named file in a directory. What if there's a service running that does not handle this correctly ( interpreted bash script that is ) - what unexpected behavior might one accomplish by naming the file weirdly?
As a benign example, consider "ls". If you create a file named "-la", then an "ls *" that tries to do a 1-deep recursive listing is going to print the extended listing with permissions and including hidden files, interpreting the "-la" as a flag instead of a file name.
PeterWhittaker|11 years ago
Note that quoting variable names is a good idea for other reasons, e.g., when a variable unexpectedly ends up empty: Not quoting such a variable can lead to termination in calls to test ([ ]), e.g., because the empty variable is replace with nothing (so that test sees the next non-whitespace token instead of the expected variable value, empty or otherwise), while quoting will at least cause the shell to correctly replace the variable with an empty string.
[1] http://www.dwheeler.com/essays/filenames-in-shell.html#summa...
santosha|11 years ago
As a benign example, consider "ls". If you create a file named "-la", then an "ls *" that tries to do a 1-deep recursive listing is going to print the extended listing with permissions and including hidden files, interpreting the "-la" as a flag instead of a file name.