Is double square brackets preferable over single square brackets in Bash

Question

A co-worker claimed recently in a code review that the       construct is to be preferred over     in constructs like   if     id -nu       someuser      then       echo  I love you madly   someuser  fi   He couldn t provide a rationale  Is there one

User · Answer

double brackets are unsuported under certain version of SunOS and totally unsuported inside function declarations by   GNU bash  version 2 02 0 1 -release  sparc-sun-solaris2 6

User · Answer

has fewer surprises and is generally safer to use  But it is not portable - POSIX doesn t specify what it does and only some shells support it  beside bash  I heard ksh supports it too   For example  you can do      -e  b      to test whether a file exists  But with    you have to quote  b  because it splits the argument and expands things like  a    where    takes it literally   That has also to do with how   can be an external program and receives its argument just normally like every other program  although it can also be a builtin  but then it still has not this special handling       also has some other nice features  like regular expression matching with    along with operators like they are known in C-like languages  Here is a good page about it  What is the difference between test    and      and Bash Tests

User · Answer

If you are into following Google s style guide   Test    and                  reduces errors as no path name expansion or word splitting takes place between    and     and           allows for regular expression matching where         does not      This ensures the string on the left is made up of characters in the   alnum character class followed by the string name    Note that the RHS should not be quoted here    For the gory details  see   E14 at https   tiswww case edu php chet bash FAQ if     filename         alnum    name     then   echo  Match  fi    This matches the exact pattern  f    Does not match in this case  if     filename      f       then   echo  Match  fi    This gives a  too many arguments  error as f  is expanded to the   contents of the current directory if    filename     f     then   echo  Match  fi

User · Answer

In a nutshell     is better because it doesn t fork another process   No brackets or a single bracket is slower than a double bracket because it forks another process

User · Answer

has more features - I suggest you take a look at the Advanced Bash Scripting Guide for more info  specifically the extended test command section in Chapter 7  Tests   Incidentally  as the guide notes        was introduced in ksh88  the 1988 version of the Korn shell

User · Answer

In a question tagged  bash  that explicitly has  quot in Bash quot  in the title  I m a little surprised by all of the replies saying you should avoid         because it only works in bash  It s true that portability is the primary objection  if you want to write a shell script which works in Bourne-compatible shells even if they aren t bash  you should avoid           And if you want to test your shell scripts in a more strictly POSIX shell  I recommend dash  though it is an incomplete POSIX implementation since it lacks the internationalization support required by the standard  it also lacks support for the many non-POSIX constructs found in bash  ksh  zsh  etc   The other objection I see is at least applicable within the assumption of bash  that         has its own special rules which you have to learn  while       acts like just another command  That is again true  and Mr  Santilli brought the receipts showing all the differences   but it s rather subjective whether the differences are good or bad  I personally find it freeing that the double-bracket construct lets me use       for grouping   amp  amp  and    for Boolean logic   lt  and  gt  for comparison  and unquoted parameter expansions  It s like its own little closed-off world where expressions work more like they do in traditional  non-command-shell programming languages  A point I haven t seen raised is that this behavior of         is entirely consistent with that of the arithmetic expansion construct           which is specified by POSIX  and also allows unquoted parentheses and Boolean and inequality operators  which here perform numeric instead of lexical comparisons   Essentially  any time you see the doubled bracket characters you get the same quote-shielding effect   Bash and its modern relatives also use             without the leading       as either a C-style for loop header or an environment for performing arithmetic operations  neither syntax is part of POSIX   So there are some good reasons to prefer          there are also reasons to avoid it  which may or may not be applicable in your environment  As to your coworker   quot our style guide says so quot  is a valid justification  as far as it goes  but I d also seek out backstory from someone who understands why the style guide recommends what it does

User · Answer

Behavior differences Some differences on Bash 4 3 11   POSIX vs Bash extension     is POSIX    is a Bash extension inspired from Korn shell   regular command vs magic    is just a regular command with a weird name    is just the last argument of      Ubuntu 16 04 actually has an executable for it at  usr bin   provided by coreutils  but the bash built-in version takes precedence  Nothing is altered in the way that Bash parses the command  In particular   lt  is redirection   amp  amp  and    concatenate multiple commands      generates subshells unless escaped by    and word expansion happens as usual      X    is a single construct that makes X be parsed magically   lt    amp  amp      and    are treated specially  and word splitting rules are different  There are also further differences like   and       In Bashese    is a built-in command  and    is a keyword  https   askubuntu com questions 445749 whats-the-difference-between-shell-builtin-and-shell-keyword   lt      a  lt  b     lexicographical comparison   a   lt  b    Same as above    required or else does redirection like for any other command  Bash extension  expr x quot  x quot    lt  x quot  y quot   gt   dev null or    quot   expr x quot  x quot    lt  x quot  y quot   quot    1    POSIX equivalents  see  How to test strings for lexicographic less than or equal in Bash     amp  amp  and        a   a  amp  amp  b   b     true  logical and   a   a  amp  amp  b   b    syntax error   amp  amp  parsed as an AND command separator cmd1  amp  amp  cmd2   a   a    amp  amp    b   b    POSIX reliable equivalent   a   a -a b   b    almost equivalent  but deprecated by POSIX because it is insane and fails for some values of a or b like   or   which would be interpreted as logical operations          a   a    a   b   amp  amp  a   b     false  Without      would be true because     amp  amp     has greater precedence than              a   a      syntax error     is interpreted as a subshell      a   a -o a   b    -a a   b    equivalent  but     -a  and -o are deprecated by POSIX  Without       would be true because -a has greater precedence than -o     a   a        a   b       amp  amp    a   b   non-deprecated POSIX equivalent  In this particular case however  we could have written just    a   a        a   b    amp  amp    a   b   because the    and  amp  amp  shell operators have equal precedence unlike          and     amp  amp     and -o  -a and     word splitting and filename generation upon expansions  split glob   x  a b       x    a b      true  quotes not needed x  a b      x    a b     syntax error  expands to   a b    a b    x         x    a b     syntax error if there s more than one file in the current directory  x  a b      quot  x quot     a b     POSIX equivalent         ab   a      true  because it does pattern matching        are magic   Does not glob expand to files in current directory    ab   a     a  glob expands  So may be true or false depending on the files in the current directory    ab   a      false  not glob expansion   and    are the same in both   and     but    is a Bash extension  case ab in  a   echo match  esac  POSIX equivalent    ab     ab       false  loses magic with    in Bash 3 2 and above and provided compatibility to bash 3 1 is not enabled  like with BASH COMPAT 3 1     ab      ab       true          ab    ab      true  POSIX extended regular expression match    does not glob expand   a    a    syntax error  No bash equivalent  printf  ab n    grep -Eq  ab    POSIX equivalent  single line data only  awk  BEGIN exit   ARGV 1    ARGV 2     ab  ab    POSIX equivalent     Recommendation  always use    There are POSIX equivalents for every       construct I ve seen  If you use       you   lose portability force the reader to learn the intricacies of another bash extension    is just a regular command with a weird name  no special semantics are involved   Thanks to St  phane Chazelas for important corrections and additions

User · Answer

From Which comparator  test  bracket  or double bracket  is fastest   http   bashcurescancer com      The double bracket is a    compound   command    where as test and the single   bracket are shell built-ins  and in   actuality are the same command   Thus    the single bracket and double bracket   execute different code       The test and single bracket are the   most portable as they exist as   separate and external commands    However  if your using any remotely   modern version of BASH  the double   bracket is supported

User · Answer

A typical situation where you cannot use    is in an autotools configure ac script  there brackets has a special and different meaning  so you will have to use test instead of   or    -- Note that test and   are the same program

[bash] Is double square brackets [[ ]] preferable over single square brackets [ ] in Bash?

Examples related to bash

Examples related to if-statement

Examples related to syntax