Skip to main content
added 107 characters in body
Source Link
Stéphane Chazelas
  • 584.8k
  • 96
  • 1.1k
  • 1.7k

[ was made an alias to test and both were made built into the shell in Unix System III (1981). Though it should be noted that some Unix variants did not have a [ command until much later after that (up to the early 2000s on some BSDs where sh is based on the Almquist shell (a test builtin has always been included in ash's source, but on those BSDs it was initially disabled)).

[ was made an alias to test and both were made built into the shell in Unix System III (1981). Though it should be noted that some Unix variants did not have a [ command until much later after that (up to the early 2000s on some BSDs where sh is based on the Almquist shell (a test builtin has always been included in ash's source, but on those BSDs it was initially disabled)).

added 131 characters in body
Source Link
Stéphane Chazelas
  • 584.8k
  • 96
  • 1.1k
  • 1.7k

[ was made an alias to test and both were made built into the shell in Unix System III (1981). Though it should be noted that some Unix variants did not have a [ command until later after that.

added 358 characters in body
Source Link
Stéphane Chazelas
  • 584.8k
  • 96
  • 1.1k
  • 1.7k

Beside ksh (all implementations), [[...]] is also supported by bash (since version 2.02) and zsh, but all three implementations are different and there are differences between each version of a same shell though the changes are generally backward compatible (a notable exception being bash's =~ operator that has been known to break a few scripts after a certain version when its behavior changed). [[...]] is not specified by POSIX, or Unix or Linux (LSB). It has been considered for inclusion a few times, but not included as the common functionality of it supported by the major shells is already covered by the [ command and the case-in-esac construct.

[[ ... ]] does know about == from the start and is equivalent to =1. A blunder of ksh's though (and is causing confusion and many bugs) is that the = and == are not an equality operator but a pattern matching operator (though the matching aspect can be disabled with quoting but with unclear rules that differ from shell to shell).

So unless you know what shell and minimum version of it your script will ever be interpreted by, it's probably safer to stick with the standard [ command.


1An exception: [[...]] was added to bash in version 2.02. Until 2.03 where it was changed, [[ x = '?' ]] would return true while [[ x == '?' ]] would return false. That is quoting did not prevent pattern matching when using the = operator in those versions, but did when using ==.

Beside ksh (all implementations), [[...]] is also supported by bash and zsh, but all three implementations are different and there are differences between each version of a same shell though the changes are generally backward compatible (a notable exception being bash's =~ operator that has been known to break a few scripts after a certain version when its behavior changed). [[...]] is not specified by POSIX, or Unix or Linux (LSB). It has been considered for inclusion a few times, but not included as the common functionality of it supported by the major shells is already covered by the [ command and the case-in-esac construct.

[[ ... ]] does know about == from the start and is equivalent to =. A blunder of ksh's though (and is causing confusion and many bugs) is that the = and == are not an equality operator but a pattern matching operator (though the matching aspect can be disabled with quoting but with unclear rules that differ from shell to shell).

So unless you know what shell and minimum version of it your script will ever be interpreted by, it's probably safer to stick with the standard [ command.

Beside ksh (all implementations), [[...]] is also supported by bash (since version 2.02) and zsh, but all three implementations are different and there are differences between each version of a same shell though the changes are generally backward compatible (a notable exception being bash's =~ operator that has been known to break a few scripts after a certain version when its behavior changed). [[...]] is not specified by POSIX, or Unix or Linux (LSB). It has been considered for inclusion a few times, but not included as the common functionality of it supported by the major shells is already covered by the [ command and the case-in-esac construct.

[[ ... ]] does know about == from the start and is equivalent to =1. A blunder of ksh's though (and is causing confusion and many bugs) is that the = and == are not an equality operator but a pattern matching operator (though the matching aspect can be disabled with quoting but with unclear rules that differ from shell to shell).

So unless you know what shell and minimum version of it your script will ever be interpreted by, it's probably safer to stick with the standard [ command.


1An exception: [[...]] was added to bash in version 2.02. Until 2.03 where it was changed, [[ x = '?' ]] would return true while [[ x == '?' ]] would return false. That is quoting did not prevent pattern matching when using the = operator in those versions, but did when using ==.

deleted 54 characters in body
Source Link
Stéphane Chazelas
  • 584.8k
  • 96
  • 1.1k
  • 1.7k
Loading
make the examples match the original question.
Source Link
Stéphane Chazelas
  • 584.8k
  • 96
  • 1.1k
  • 1.7k
Loading
a few references
Source Link
Stéphane Chazelas
  • 584.8k
  • 96
  • 1.1k
  • 1.7k
Loading
added 34 characters in body
Source Link
Stéphane Chazelas
  • 584.8k
  • 96
  • 1.1k
  • 1.7k
Loading
Source Link
Stéphane Chazelas
  • 584.8k
  • 96
  • 1.1k
  • 1.7k
Loading