Error with if [ -n $diffCurr ]: Too many arguments

Question

I have been using the below code ok for sometime, but now, I get an error

java Editor < "input/editor$i.in" > "tmp/editor$i.out"
diffCurr="$(diff "tmp/editor$i.out" "output/editor$i.out")"
if [ -n $diffCurr ]

Error (occurs on last line of above snippet):

[: too many arguments

Whats wrong? I am trying to test that the diff result was empty (ie. same contents in file)

Answer 1

There's no need to put the output of diff in a variable, since you can tell whether files differ based on the exit status of diff, e.g.

if diff -q file1 file2 >/dev/null 2>&1; then
        # files are equal
else
        # files differ, or an error occurred
fi

diff returns success (0) if the files do not differ. Adjust the logic as necessary.

Testing exit statuses of commands when possible is almost always preferred over checking or parsing output via command substitution.

For the sake of completeness, the error with your original example happened because you didn't quote "$diffCurr" in the if line, so it went through "word splitting" into more than one word --- hence "too many arguments".

Answer 2

jw013 is right, you don't need this line anyway.

But to answer the actual question, you have left out quotation marks around the variable that you passed into test (otherwise known as [).

This means if your variable is empty, it will be as if you had no arguments (eg [ -n ]), and if your variable contains spaces, it will be as if you passed multiple arguments (I'm guessing this is what happened).

Always wrap the strings under test with quotes, eg:

if [ -n "$myvar" ]

Answer 3

It may be better to test the exit code of the diff command than the output.

diffCurr="$(diff "tmp/editor$i.out" "output/editor$i.out")"
if [ $? -ne 0 ]; then  # different
...

If you are not interested in the output, then you can do as jw013 suggests.

Answer 4

In addition to the good answers above: My love/hate relationship with bash is focused primarily around its strength in parameter substitution and in the fact that getting it to stop substituting when you want it to can be quite challenging - especially when a variable gets used or altered more than once.

As a result, I almost always code variable references like:

A="${B}"

This makes sure B gets treated as a single string (most often what I want) and it allows things like

A="${B}foo"

to work as well as a bunch of other fancy options that only work inside the braces.

If I code even a simple safe variable reference as

A="${B}"

to start with, I'm a lot safer when I go back in to modify the code later and possibly do something that might fail if the quotes or braces were missing.