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.

Arronical
  • 280
  • If you want them to undergo further expansion/word splitting. – 123 Nov 18 '16 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. – magor Nov 18 '16 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 – Chris Davies Nov 18 '16 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. – Arronical Nov 18 '16 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" – Chris Davies Nov 18 '16 at 10:38
  • @roaima for example if [[ "${nr}" -lt 1 ]] . the answer given by you contains some cases which i should treat differently i guess – magor Nov 18 '16 at 10:41
  • @roaima that answer does contain the information needed to figure out where you may want to not quote. I suppose I'd not really taken it in properly, maybe because I'd started thinking of other methods to reach some of those outcomes as I read it. – Arronical Nov 18 '16 at 10:50

3 Answers3

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.

Chris Davies
  • 116,213
  • 16
  • 160
  • 287
  • These examples are OK only when the variables will never contain user input, as globbing will still be done. – Muzer Nov 18 '16 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. – Chris Davies Nov 18 '16 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 :( – Muzer Nov 18 '16 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.

Sergiy Kolodyazhnyy
  • 16,527
  • 1
    Both of these are really bad, because shell globbing is still applied. Try making one of your array elements an asterisk. – Muzer Nov 18 '16 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 :) – Sergiy Kolodyazhnyy Nov 18 '16 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... – Muzer Nov 18 '16 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 – Sergiy Kolodyazhnyy Nov 18 '16 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.

mikejonesey
  • 2,030