On 03/14/2011 01:34 AM, Philipp Hahn wrote:
> Meanwhile, I'm not a fan of blindly quoting everything; there
are
> documented cases where you can trigger shell bugs by doing too much
> quoting. For example:
>
> foo=`some_command "with quotes"`
>
> is portable, but
>
> foo="`some_command "with quotes"`"
>
> is not. So I prefer to quote variables that come from external source,
> but not internal variables that are obviously safe (that said, quoting
> generally doesn't hurt, so even if something is overkill does not meant
> that I am rejecting the patch).
I've seen to many scripts not doing any quoting at all or all wrong, which
fail in interesting to horrible ways when given arguments containing shell
meta characters. I personally consider them a much greater risk than some
ancient shell not being able to parse properly quoted strings.
Those two lines are identical in behavior on a correct shell, whereas
the one without redundant quoting is the only one of the two that also
works on buggy shells, therefore it is a case of being more portable by
not adding redundant quotes with no loss in functionality. Remember, no
word splitting or filename expansion is performed in assignment context,
so quoting is redundant in those cases where you are assigning a single
shell word, such as a command substitution.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org