3

I'm aware of several situations where it's unnecessary to use double quotes when expanding a variable in Bash, such as inside [[...]], or when used on the right hand side of a variable assignment.

When reading about quoting variables I often hear that it's often better to just use double quotes everywhere, as there are only a very few cases where you wouldn't want them.

What are the cases where behaviour from quoting is undesirable? I'm not talking about situations where you don't need to quote, but where quoting a variable will actively stop something from working.

Improve this question
7
  • If you want them to undergo further expansion/word splitting. Commented Nov 18, 2016 at 10:07
  • my code reviews won't pass if i use unquoted variables. simply put, at my job it's not allowed to use unquoted variables ever. Commented Nov 18, 2016 at 10:15
  • @mazs how do you handle the situation where you've got, say, verbose=; [[ some_condition ]] && verbose=-v; ...; some_program $verbose some_args Commented Nov 18, 2016 at 10:29
  • @Serg I had read and understood the suggested dupe before asking the question. I want to now if there are any specific situations where quoting should be explicitly avoided. Commented Nov 18, 2016 at 10:29
  • Why don't you think Gilles' response in the suggested dup answers your modified question? Especially the part starting "An unquoted variable and command substitution is be useful in some rare circumstances" Commented Nov 18, 2016 at 10:38

3 Answers 3

Reset to default
3

Don't quote when you want an empty variable to disappear (as distinct from remaining as an empty string):

verbose= [[ some_condition ]] && verbose=-v # ...later... some_program $verbose some_args

Don't quote when your variable contains whitespace separated arguments and you want the shell to treat them as separate words

exclude_file= [[ -s excludelist.txt ]] && exclude_file='--exclude excludelist.txt' # ...later... rsync -avP $exclude /path/to/source/ remote:target

The general approach is always to use double-quotes unless you know why you don't want them.

Improve this answer
3
  • These examples are OK only when the variables will never contain user input, as globbing will still be done. Commented Nov 18, 2016 at 10:42
  • @Muzer or when you really want the user input to be globbed (I don't have an example for that to hand as usually I expect the shell to handle that before my code sees it). I might put my last sentence in bold to emphasise it. Commented Nov 18, 2016 at 10:57
  • Indeed. I guess the case where you're interactively reading in something that the user expects to be interpreted with normal shell semantics. Maybe if you're writing a shell in bash? :D (Though will that work with things like quoting filenames/escaping spaces? I haven't actually tried that) EDIT: Just tried, no it doesn't :( Commented Nov 18, 2016 at 11:09
1

Avoiding quoting is desirable when we want shell to think "oh, these are all separate elements, not one whole!". Such thing can be quite useful with arrays. 

bash-4.3$ var="one two three" bash-4.3$ arr=( $var ) bash-4.3$ for i in "${arr[@]}"; do echo "$i"; done one two three

In particular , this is useful when you are generating an array as in example above. I've personally used such approach when enumerating actual addresses of the Ubuntu workspaces ( exact terminology is viewports, and they use format of coordinates like X,y , but that's whole lot different story ).

Another approach is when you're giving the variable to another command that needs to process them as separate items. Compare:

bash-4.3$ bash -c 'for item; do echo $item; done' sh "$var" one two three bash-4.3$ bash -c 'for item; do echo $item; done' sh $var one two three

To address what has been mentioned in the comments, these examples aren't meant to be used with "unexpected input", and rather for controlled environment. In addition, set noglob can be used if globing is to be avoided, but again - if you are generating an array for certain combination of strings such as numeric values of desktop viewports, there's no danger from glog at all. If you're dealing with actual user input, then quotes are to be used, and this is not what was the topic of this question.

Improve this answer
4
  • 1
    Both of these are really bad, because shell globbing is still applied. Try making one of your array elements an asterisk. Commented Nov 18, 2016 at 10:41
  • @Muzer sure, globbing is still applied. That's one of the things you have to keep in mind when using shells, and if you're writing actual script, then checks should be made. This is just a simple approach to creating array out of a one whole string, and I'm not going whole 9 yards here. Ease up on judgement :) Commented Nov 18, 2016 at 10:46
  • The whole reason you use quotes is because you want to go the whole 9 yards in terms of making your program robust against unexpected input. Not going the whole 9 yards is the way security bugs appear in software... Commented Nov 18, 2016 at 10:48
  • 1
    @Muzer This particular question asks "When quoting is not desirable?" , and I am giving specific answer - when we do want word splitting to occur. Nobody is questioning the need for quotes in other situations Commented Nov 18, 2016 at 10:52
-2

[] = builtin, increased portability

[[]] = compound command, increased functionality

propose using single brackets when creating script that is indented to be shared across a number of platforms.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.