Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This was part of fetchmail deamon script,

if [ ! "x$START_DAEMON" = "xyes" -a ! "$1" = "status" ]; then

What's the point of using x$START_DAEMON = "xyes", why not just use $START_DAEMON = "yes" ?

share|improve this question
up vote 8 down vote accepted

I've seen cases where the x$variable was not quoted, and in that case it's to handle situations where the variable ($START_DAEMON in this case) might be empty. Otherwise, your test would be checking whether ! = "yes", and the test would error. However, as you've pointed out in comments, double-quoting the x$variable takes care of this.

On the other hand, a question on ServerFault led me to this page: http://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html, wherein one is preventing the variable expansion from starting with a character that may confuse [ or test

Even so, I think this is an issue that may only be a problem in older ("Historical" as the opengroup page says) shells, and that newer implementations do the right thing without the x, so long as double-quotes are involved at least. So it may primarily be a coding tradition. I was able to confirm a problem using /bin/sh on SunOS 5.10, though:

 # a="!"; [ "$a" = "yes" ] && echo ok
 test: argument expected
share|improve this answer
unset a;[ "$a" = "yes" ] && echo ok that doesn't report error, hmm – warl0ck Oct 8 '12 at 5:19
Right you are. I have seen cases where x$variable was not quoted, and it may have been those situations where problems with test arose. However, using a known character like x does prevent other problems with special characters -- I'll update the answer. – Lars Rohrbach Oct 8 '12 at 5:47
It can also be a shell quoting issue. For example, Bash 4.2.24 complains bash: !: event not found with your posted example, but avoids history expansion and works fine with a=\!; [[ "$a" = "yes" ]] && echo ok instead. – CodeGnome Oct 8 '12 at 6:40
POSIX mandates the parsing of all correct test expressions up to three tokens, such as this one. Historical Bourne shells are buggy. The x prefix makes the left-to-right parsing unambiguous. The double quotes are necessary in any shell, in case the value of the variable is empty, contains spaces, etc. The double quotes aren't necessary inside [[…]] which is special syntax, not a mere built-in utility like [. – Gilles Oct 8 '12 at 22:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.