In shell, "if" just looks at the exit status of the next set of commands.
if ls /path ; then echo foo ; fi
works just as well as the sugar wrapping "test" ( [ ] ) or extended builtins.
if ls /path ; then echo foo ; fi
works just as well as the sugar wrapping "test" ( [ ] ) or extended builtins.
-- -- bash:~]$ if $var < 21; then echo "smaller"; fi
bash: 21: No such file or directory
-- -- BUT this works:
if (( $var < 21 )); then echo "smaller"; fi
smaller
-- -- BUT this DOESN'T:
if [[$var < 21 ]]; then echo "smaller"; fi
bash: 21: No such file or directory
-- -- BUT this DOES (added a space after '[['):
if [[ $var < 21 ]]; then echo "smaller"; fi
smaller
Plus the fact that having to type out 'then' and 'fi' and that semi-colons are semi-necessary are annoying. Compared to today's languages, very little of the non-posix parts of bash feel well though out. We can do better.
All these things make it necessary to understand bash. Most modern programming languages feel familiar. Bash and Sh don't anymore. They feel antiquated.
One of my biggest annoyances with shell is that there are these magic programs such as [ that pretend to be part of the language but aren't.
If if $var has an exit status (because perhaps you insanely want to have var be some program set elsewhere) your if statement would work....
These other examples have operators (test or similar expanded builtins), and those set the exist status that the if block reads.
so grep -q hacker < /etc/passwd if [ $? -eq 0 ] ; then echo hackd! ; fi
is an indirect way of saying:
if grep -q hacker < /etc/passwd ; then echo hackd! ; fi
Shell is terrible, but the way people use it makes it even worse because the sugar hides what's actually going on.
$ if (( $var < 21 )); then echo "smaller"; fi
smaller
$ if [[ $var < 21 ]]; then echo "smaller"; fi
smaller
$ if [[ $var < 21 ]] { echo "smaller" }
smaller