1

I believe this line

if test "$suman_inspect" -eq "yes"; then

is causing this error (verbatim):

bash: test: no: integer expression expected

I formulated the above test expression because I saw this example online:

 if test "$#" -eq "0"; then

where this test checks to see if the length of the arguments array is 0.

So is there something wrong with both these checks? I am not sure I understand how the first could be valid but the second one invalid.

1 Answers1

4

Note that -eq is for integer comparisons. For string comparisons, use == (or =). Thus, you should use the following:

if test "$suman_inspect" == "yes"; then
    # do something
fi

The same distinction applies for inequality operators (-gt, -lt, -ge, -le, and -ne being used for numerical comparisons, and >, <, >=, <=, and != being used for string comparisons).

Note that you can also use [ expression ] in place of test expression; the two are synonymous.

user001
  • 3,698
  • yeah it's a shame the -eq operator cannot compare two strings, as long as both arguments are already strings, oh well. – Alexander Mills Nov 10 '17 at 00:54
  • @Alexander Mills: I have long thought that eq, being a string, should be used for string comparisons, while =, being a mathematical symbol, should be used for numerical comparisons, but alas it's not the case. – user001 Nov 10 '17 at 00:57
  • no language is perfect lol – Alexander Mills Nov 10 '17 at 01:03
  • @AlexanderMills String and integer comparisons are different, so it's important to have different symbols for them. For instance, [ 05 -eq 5 ] is true, but [ 05 = 5 ] is not -- they're different strings that represent the same integer. Also, [ 5 -lt 11 ] is true, but [ 5 '<' 11 ] is not, because 5 is less than 11 numerically, but comes after it "alphabetically" (i.e. in sorting order). BTW, = is preferred over == with test and [ ], for compatibility reasons. – Gordon Davisson Nov 10 '17 at 03:06