BASH Syntax Checking Debug Mode Malfunction? - linux

Question

We can use bash -n script.sh to validate the syntax of a shell script. However, when I was trying to test this function, I noticed not all the syntax errors could be found by this option.
For example:
root#ubuntu:~/testenv# cat test
#!/bin/bash
SEND=1
if [ "$SEND" -eq 0 ]
echo no
fi
Now, let's test the script:
root#ubuntu:~/testenv# bash -n test
test: line 5: syntax error near unexpected token `fi'
test: line 5: `fi'
It works fine. However, if I just remove one of the bracket:
root#ubuntu:~/testenv# cat test
#!/bin/bash
SEND=1
if [ "$SEND" -eq 0
then
echo no
fi
root#ubuntu:~/testenv# bash -n test
root#ubuntu:~/testenv#
Nothing happened!
I also checked the man page of bash, it describes the "-n" is:
-n Read commands but do not execute them. This may be used to check a
shell script for syntax errors. This is ignored by interactive
shells.
It is a script file, so it shouldn't be an "interactive shell" right? So,how could this happen?

Answer 1

I'm guessing you have run into a very strange quirk of the way the shell implements single-bracketed conditionals: [ is a command, not a special character. Look in your system executable directory (probably /usr/bin) and you will find an executable file literally named [ which implements this command. When you write something like
[ "$SEND" -eq 0 ]
then you're actually invoking the command [ with four arguments:
The value of $SEND
The string -eq
The string 0
The string ]
The command [ checks that the last argument is ] (because it would look weird otherwise), then puts the remaining arguments together to form a condition and return the result of testing the condition.
Now, because [ is a command, it's not a syntax error to invoke that command with any set of arguments you like. Sure, if you leave off the trailing ], you will get an error, but that error comes from the command [, not from the shell. That means you have to actually run the script to get the error - the syntax checker won't see anything wrong with it. As far as bash is concerned, [ is just a command name, no different from, say, my_custom_conditional_test, and if you were to write
my_custom_conditional_test "$SEND" -eq 0
it would be obvious that this is fine, right? Bash thinks of [ the same way.
I should note that for efficiency, bash doesn't actually use the executable file /usr/bin/[; it has its own builtin implementation of [. But people expect [ to act the same way regardless of whether it's built in to the shell or not, so the Bash syntax checker can't give its own [ special treatment. Since it wouldn't be a syntax error to invoke /usr/bin/[ with no trailing ], it can't be a syntax error to invoke the builtin [ without a ].
You can contrast this with [[, which does more or less the same thing (testing a condition) but is given special meaning by the shell. [[ is a special token in shell syntax, not a command. If you write [[ instead of [, and you omit the corresponding trailing ]], you bet Bash is going to complain about a syntax error.