There is a story about this that is not very well understood: the Bourne shell is a language to handle values like processes, return codes, pipes, and rather secondarily strings, even if less so than the v6 shell.

So if and while test process returns codes, not numbers or strings. Nearly all operations other than on processes, return codes, pipes were supposed to be done using processes, so test and expr mainly (and grep, sed, awk, that is shell scripts are oriented at processing bulk streams with pipelines, else use perl as programming language).

The string exception is because of environment variables, and it major manifestation is the builtin case statement. I still cringe when I see silly things like:

if [ x$N -eq xyes ]; then
  ...
fi

instead of:

case "$N" in
[Yy][Ee][Ss]) ...;;
[Nn][Oo])     ...;;
 *) echo 1>&2 "$0: option N must be 'yes' or 'no' not '$N'"
    exit 1;;
 esac

Example: http://www.sabi.co.uk/Cfg/shell/sabidhclinux

if [ x$N = xyes ]; then

Not really on topic here, but: I've seen people do this frequently. Mostly by people that are - apparently - not very familiar with double quotes, so you can rewrite this as :

if [ "$N" = "yes" ]; then

which gives you the same (or better) results, but without the silly need of placing the additional and confusing two additional 'x'. (or simpler than your 'case' example, which might be unneeded depending on what you are trying to do).

PS: And I think that in your example, you might have meant '$var = yes' which is for string comparison, and not '$var -eq yes' which is for integer comparison.

I had misremembered the xyes thing as being a workaround for the case when $N is empty, so some implementations would treat this as an erroneous two-argument form. But it's not very plausible that even old broken shells would skip the "" entirely rather than parse it an an empty argument.

The autoconf manual (a useful compendium of shell lore) lists this as instead being a workaround for $N values like ! or -n which would otherwise lead to parsing confusion. Which is a reasonable concern if you might see such (malicious) values in your input.

My big problem in this area is remembering which of test $a = $b and test $a == $b is portable and which is Bash-specific.

I had misremembered the xyes thing as being a workaround for the case when $N is empty

Actually, I think this is exactly why people do this; it just seems they do not seem to know you don't need to do it when you doublequote things.

Also, the reference to the autoconf manual seems interesting (and I think i'll read it), thanks for mentioning that.

According to posix (Documentation of "test", the "APPLICATION USAGE" section), the practice of prefixing x to the values is not about ensuring it's empty (if unquoted), but rather because apparently early versions could get confused if the first argument beging with "-":

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/test.html

------------------>8----------------

Historical systems have also been unreliable given the common construct:

test "$response" = "expected string"

One of the following is a more reliable form:

test "X$response" = "Xexpected string" test "expected string" = "$response"

Note that the second form assumes that expected string could not be confused with any unary primary. If expected string starts with '-', '(', '!', or even '=', the first form should be used instead. Using the preceding rules, any of the three comparison forms is reliable, given any input. (However, note that the strings are quoted in all cases.)