Thanks Gödel. But that link contains severe errors.
They use the term "pattern matching" where they mean "string comparison" - two different concepts.
Much more troubling that FAIL to correctly describe the distinction between string and integer comparison operators.
In "old Bash"" single '[' as they call it, they claim that \> and -gt can be used interchangeable for integer comparison but that is provably false. \> is always and only a STRING comparison and -lt is always and only an integer comparison, Here is an example of the error
[stevea@crucibulum Desktop]$ [ 5 \< 6 ] && echo YES || echo NO
[stevea@crucibulum Desktop]$ [ 5 -lt 6 ] && echo YES || echo NO
[stevea@crucibulum Desktop]$ [ 5 -lt 06 ] && echo YES || echo NO
[stevea@crucibulum Desktop]$ [ 5 \< 06 ] && echo YES || echo NO
So clearly the \< type operators always promote their arguments to string types and then compare these lexically. 5 is lexically less than 6 but not lexically less than 06.
Any scripts written with the wrong type of operator may fail to operate as intended given perfectly valid input.
So as the bash man page states clearly under "CONDITIONAL EXPRESSIONS"
"-eq, -ne, -lt, -le, -gt, or -ge" are arithmetic binary operators, and
"= == != < >" are string binary operators.
THEY ARE NOT INTERCHANGEABLE.
The bottom line is that '[[' is less portable. It is NOT defined by POSIX which only allows it as an implementation specific keyword. My personal concerns always go to porting scripts to embedded systems with old v3 bash or even busybox 'sh'.
I'm not suggesting anyone NOT use '[[', but one must consider if there is compelling value.
That '[[' makes the quoting unnecessary is a small value, but it also makes the already complex bash quoting scheme even more complex. When we see
then we naturally expect that cmd has two arguments (argc=3), but with the peculiar '[[' scheme violates that expectation.
I'll scan the source but the advantages look slim to me.