bash vs zsh – Why `==` Behaves Differently Inside `[ … ]`

bashtestzsh

I get what I expected when doing this in bash:

[ "a" == "a" ] && echo yes

It gave me yes.

But when I do this in zsh, I get the following:

zsh: = not found

Why does the same command (/usr/bin/[) behave differently in different shells?

Best Answer

It's not /usr/bin/[ in either of the shells. In Bash, you're using the built-in test/[ command, and similarly in zsh.

The difference is that zsh also has an = expansion: =foo expands to the path to the foo executable. That means == is treated as trying to find a command called = in your PATH. Since that command doesn't exist, you get the error

zsh: = not found

that you saw (and in fact, this same thing would happen even if you actually were using /usr/bin/[).

You can use == here if you really want. This works as you expected in zsh:

[ "a" "==" "a" ] && echo yes

because the quoting prevents =word expansion running. You could also disable the equals option with setopt noequals.

However, you'd be better off either:

Using single =, the POSIX-compatible equality test; or
Better still, using the [[ conditionals with == in both Bash and zsh. In general, [[ is just better and safer all around, including avoiding this kind of issue (and others) by having special parsing rules inside.

Related Solutions

Why Does the Exclamation Mark `!` Sometimes Upset Bash?

The ! character invokes bash's history substitution (enabled by default in interactive shells). When followed by a string (as in your failing example) it tries to expand to the last history event that began with that string. Just like $var gets expanded to the value of that string, !echo would expand to the last echo command in your history.

Space is a breaking character in such expansions. First note how this would work with variables:

# var="like"
# echo "$var"
like
# echo "$"
$
# echo "Do you $var frogs?"
Do you like frogs?       <- as expected, variable name broken at space
# echo "Do you $varfrogs?"
Do you?                  <- $varfrogs not defined, replaced with blank
# echo "Do you $ var frogs?"
Do you $ var frogs?      <- $ not a valid variable name, ignored

The same thing will happen for history expansion. The bang character (!) starts off a history replacement sequence, but only if followed by a string. Following it with a space make it literal bang instead of part of a replace sequence.

You can avoid this kind of replacement for both variable and history expantion by using single quotes. Your first examples used single quotes and so ran fine. Your last examples are in double quotes and thus bash scanned them for expantion sequences before it did anything else. The only reason the first one didn't trip is that that the space is a break character as shown above.

Bash – For loops in zsh and bash

Several forms of complex commands such as loops have alternate forms in zsh. These forms are mostly inspired by the C shell, which was fairly common when zsh was young but has now disappeared. These alternate forms act exactly like the normal forms, they're just a different syntax. They're slightly shorter, but less clear.

The standard form for the for command is for x in 1 2 3; do echo $x; done, and the standard form for the while command is while test …; do somecommand; done. Ksh, bash and zsh have an alternate form of for: for ((i = 0; i < 42; i++)); do somecommand; done, which mimics the for loops of languages like Pascal or C, to enumerate integers. Other exotic forms that exist in zsh are specific to zsh (but often inspired by csh).

Best Answer

Related Solutions

Why Does the Exclamation Mark `!` Sometimes Upset Bash?

Bash – For loops in zsh and bash

Related Question