On 3 October 2014 22:45, Steve Coile <user-a2e2f9aff0d1@xymon.invalid>
wrote:
Suppose /usr/bin/zonename returned "-f", producing:
[ -f = global ]
No, it would produce:
[ "-f" = "global" ]
which would fail to match of course, but would not produce a parsing
mistake, which I assume is the reason for the "x" prefix. The "-f" would
not cause the shell to test for the existence of a file.
Actually, even an unquoted "-f" doesn't seem to fail to parse in this way.
A better test is to use "-eq", like this:
$ [ `echo 0 -eq` = "global" ] && echo true || echo false
-bash: [: =: integer expression expected
false
$ [ "`echo 0 -eq`" = "global" ] && echo true || echo false
false
The first example triggers the type of parsing problem that I think you are
referring to, and trying to protect against. The second one, with the
double quotes around the expression, eliminates the problem.
Richard's approach is a good one in the general case, even if in this case
it's very unlikely to have any practical effect. I use Richard's approach
myself. You should, too. :)
Richard's way works, so that's fine. As a matter of style, I don't like it
because it's not clear what it's trying to do, and distracts from the
readability of the code. The fact that Richard felt he needed to explain
the reason for the "x" reinforces my view on this. I won't be using the
this technique; and instead, for improved readability I'll continue to
recommend that people rely on double quotes.
Cheers
Jeremy