Can't Find Unexpected Operator (Bash Error)

Can't find unexpected operator (Bash error)

Always protect your bash variables with double quotes in test expressions:

   if [ -e "$dir" ] && [ -d "$dir" ]; then

Unexpected operator error

You need to use = instead of == in the [ $? == 0 ] line.

Why am i getting an unexpected operator error in bash string equality test?

You can't use == for single bracket comparisons ([ ]). Use single = instead. Also you must quote the variables to prevent expansion.

if [ "$bn" = README ]; then

If you use [[ ]], that could apply and you wouldn't need to quote the first argument:

if [[ $bn == README ]]; then

ShellScript 1: [: [: unexpected operator

Don't use the brackets at all.

if cmp -s 1.fsa 1_.fsa; then
  echo "Files are identical!"
else
  echo "Files are different!"
fi

[ ] runs a command called test. If you read man test, you'll see that it doesn't understand "returns any" to mean anything at all; neither does it expect to see [ passed to it.

So, the literal error you got:

[: [: unexpected operator

means that the [ command (aka test) is complaining that it doesn't expect to be passed [ as an argument.

Unexpected operator from [ $var -eq 1 ]

This is one of those matter where quotes are important; when $USE_TEST is not defined, your statement expands to:

if [ -eq 1 ]; then

The common fix:

if [ "$USE_TEST" -eq 1 ]; then

...though that would also imply switching to a string comparison, because -eq will break with an empty string:

if [ "$USE_TEST" = 1 ]; then

But you may also consider using [[ (which is a bash builtin) or ${USE_TEST:-0} (which specifies a default value).

Unexpected operator in if statement

The script you’ve posted has various issues, which are highlighted by ShellCheck:

Line 1:
echo "\nContinue downloading? [y/n]"
     ^-- SC2028: echo may not expand escape sequences. Use printf.

Line 2:
read CONTINUE
^-- SC2162: read without -r will mangle backslashes.

Line 5:
if [ $CONTINUE != "y" ] && [ $CONTINUE != "n" ]; then
     ^-- SC2086: Double quote to prevent globbing and word splitting.
                             ^-- SC2086: Double quote to prevent globbing and word splitting.

Did you mean: (apply this, apply all SC2086)
if [ "$CONTINUE" != "y" ] && [ "$CONTINUE" != "n" ]; then

Line 7:
elif [ $CONTINUE = "n" ]; then
       ^-- SC2086: Double quote to prevent globbing and word splitting.

Did you mean: (apply this, apply all SC2086)
elif [ "$CONTINUE" = "n" ]; then

Line 8:
    echo "\nDonwload terminated!"
         ^-- SC2028: echo may not expand escape sequences. Use printf.

But despite these issues the script actually otherwise works as expected on Debian (Buster)’s default shell (which is dash). You might be running a non-default shell. The easiest way to solve your issue is therefore to

• Declare a valid shebang line
• Fix the issues highlighted above.

Which leaves us with this:

#!/bin/sh

printf "\nContinue downloading? [y/n] "
read -r CONTINUE

error() {
    printf >&2 '%s\n' "$@"
    exit 1
}

if [ "$CONTINUE" != y ] && [ "$CONTINUE" != n ]; then
    error "Invalid argument"
elif [ "$CONTINUE" = n ]; then
    printf "\nDownload terminated!\n"
    exit
fi

(This also adds a definition for the undefined error call; substitute as appropriate.)

Amazon CLI bash script on Ubuntu 16.04, unexpected operator on if statements (syntax looks correct)

This breaks:

monthNumber=$(date + '%m')

it has to be

monthNumber=$(date +'%m')

but I suspect it's just a typo as it would prevent your error message from appearing.

You are probably running this as follows:

sh ./backup.sh

which means that the #!/bin/bash line is ignored, and either Bash in POSIX mode or another shell altogether is run. == is not POSIX, so you have to change

if [ $# -lt 1 ] && [ "$dayOfWeek" == "$weekly_backup_day" ]

to

if [ $# -lt 1 ] && [ "$dayOfWeek" = "$weekly_backup_day" ]

or run it with

bash ./backup.sh

or just

./backup.sh

Consider:

$ sh -c '[ 1 == 1 ] && echo Yes'      # Can't have "==" in sh
sh: 1: [: 1: unexpected operator
$ sh -c '[ 1 = 1 ] && echo Yes'       # "=" is okay
Yes
$ bash -c '[ 1 == 1 ] && echo Yes'    # Bash does not care either way
Yes
$ bash -c '[ 1 = 1 ] && echo Yes'
Yes
$ bash -c '(( 1 == 1 )) && echo Yes'  # (( )) is a Bashism
Yes

---

As for "why quote", the summary is "because of word splitting and glob expansion". The Wooledge wiki has a good article about it.

---

Related Topics