Are double square brackets [[ ]] preferable over single square brackets [ ] in Bash?

Question

A coworker 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?

Solution 1

[[ 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

Solution 2

Behavior differences

Some differences on Bash 4.3.11:

• POSIX vs Bash extension:

  • [ is POSIX
  • [[ is a Bash extension inspired from KornShell

• 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, < is redirection, && 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. <, &&, || 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: What's the difference between shell builtin and shell keyword?

• <

  • [[ a < b ]]: lexicographical comparison
  • [ a \< b ]: Same as above. \ required or else does redirection like for any other command. Bash extension.
  • expr x"$x" \< x"$y" > /dev/null or [ "$(expr x"$x" \< x"$y")" = 1 ]: POSIX equivalents, see: How to test strings for lexicographic less than or equal in Bash?

• && and ||

  • [[ a = a && b = b ]]: true, logical and
  • [ a = a && b = b ]: syntax error, && parsed as an AND command separator cmd1 && cmd2
  • [ a = a ] && [ 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) && a = b ]]: false. Without ( ) it would be true, because [[ && ]] 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 \( \) it would be true, because -a has greater precedence than -o
  • { [ a = a ] || [ a = b ]; } && [ a = b ] non-deprecated POSIX equivalent. In this particular case however, we could have written just: [ a = a ] || [ a = b ] && [ a = b ], because the || and && shell operators have equal precedence, unlike [[ || ]] and [[ && ]] and -o, -a and [

• word splitting and filename generation upon expansions (split+glob)

  • x='a b'; [[ $x = 'a b' ]]: true. Quotes are not needed
  • x='a b'; [ $x = 'a b' ]: syntax error. It 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'; [ "$x" = 'a b' ]: POSIX equivalent

• =

  • [[ ab = a? ]]: true, because it does pattern matching (* ? [ are magic). Does not glob expand to files in the current directory.
  • [ ab = a? ]: a? glob expands. So it 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 and ? 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, and no special semantics are involved.

Thanks to Stéphane Chazelas for important corrections and additions.

Solution 3

From Which comparator, test, bracket, or double bracket, is fastest?:

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.

Solution 4

If you are into following Google's style guide:

Test, [ … ], and [[ … ]]

[[ … ]] is preferred over [ … ], test and /usr/bin/[.

[[ … ]] reduces errors as no pathname expansion or word splitting takes place between [[ and ]]. In addition, [[ … ]] allows for regular expression matching, while [ … ] 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.
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

For the gory details, see E14 at http://tiswww.case.edu/php/chet/bash/FAQ

Solution 5

In a question tagged 'bash' that explicitly has "in Bash" 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, && and || for Boolean logic, < and > 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, "our style guide says so" 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.

View more solutions

Comments

[guns]

Considering that bash is everywhere these days, I tend to think it's pretty damn portable. The only common exception for me is on busybox platforms - but you'd probably want to make a special effort for it anyways, given the hardware that it runs on.

[A B]

Test and [ are names for the same builtin command in bash. Try using type [ to see this.

[Lightness Races in Orbit]

@guns: Indeed. I'd suggest that your second sentence disproves your first; if you consider software development as a whole, "bash is everywhere" and "the exception is busybox platforms" are completely incompatible. busybox is widespread for embedded development.

[Jens]

What's with the obsession of fastest in shell scripts? I want it most portable and couldn't care less about the improvement [[ might bring. But then, I'm an old school old fart :-)

[dubiousjim]

@guns: Even if bash is installed on my box, it might not be executing the script (I might have /bin/sh symlinked to some dash-variant, as is standard on FreeBSD and Ubuntu). There's additional weirdness with Busybox, too: with standard compilation options nowadays, it parses [[ ]] but interprets it as meaning the same as [ ].

[dubiousjim]

I think many shells prove builtin versions of [ and test even though external versions also exist.

[Tim Gilbert]

@alberge, that's true, but [[, as distinct from [, is syntax interpreted by the bash command-line interpreter. In bash, try typing type [[. unix4linux is correct that although classic Bourne-shell [ tests fork off a new process to determine the truth value, the [[ syntax (borrowed from ksh by bash, zsh, etc) does not.

[A B]

@Tim, I'm not sure which Bourne shell you're talking about, but [ is built-in to Bash as well as Dash (the /bin/sh in all Debian-derived Linux distributions).

[Tim Gilbert]

Oh, I see what you mean, that's true. I was thinking of something like, say, /bin/sh on older Solaris or HP/UX systems, but of course if you needed to be compatible with those you wouldn't be using [[ either.

[Nick Matteo]

@dubiousjim: If you use bash-only constructs (like this one), you should have #!/bin/bash, not #!/bin/sh.

[michael]

@Jens in general I agree: the whole purpose of scripts is (was?) portability (otherwise, we'd code & compile, not script)... the two exceptions I can think of are: (1) tab completion (where completion scripts can get really long with lots of conditional logic); and (2) super-prompts (PS1=...crazy stuff... and/or $PROMPT_COMMAND); for these, I don't want any perceptible delay in the execution of the script.

[michael]

very true, and not at all inconsequential. bash portability across older versions must be considred. People say "bash is ubiquitous and portable, except for maybe (insert esoteric OS here)" -- but in my experience, solaris is one of those platforms where special attention must be paid to portability: not only to consider older bash versions on a newer OS, issues/bugs w/ arrays, functions, etc; but even utilities (used in the scripts) like tr, sed, awk, tar have oddities & peculiarities on solaris that you have to work-around.

[scavenger]

you are so right... so much utilities non POSIX on Solaris, just look at the "df" output and arguments... Shame on Sun. Hopefully it's disappearing little by little (except in Canada).

[peterh]

Solaris 2.6 seriously? It was released in 1997 and ended support in 2006. I guess if you're still using that then you have other problems!. Incidentally it used Bash v2.02 which was the one that introduced double brackets so should work even on something as old as that. Solaris 10 from 2005 used Bash 3.2.51 and Solaris 11 from 2011 uses Bash 4.1.11.

[peterh]

Re Script portability. On Linux systems there's generally only edition of each tool and that is the GNU edition. On Solaris you typically have a choice between a Solaris-native edition or the GNU edition (say Solaris tar vs GNU tar). If you depend on GNU specific extensions then you must state that in your script for it to be portable. On Solaris you do that by prefixing with "g", e.g. ` ggrep` if you want the GNU grep.

[anthony]

That is why I make my scripts use #!/bin/sh but then switch them to use #!/bin/bash as soon as I rely on some BASH specific feature, to denote it is no longer Bourne shell portable.

[Dan Pritts]

bash is available in ports, but not installed by default, on FreeBSD. Similar on solaris last I checked, but that was quite a while ago. Probably AIX too. Admittedly, much smaller installed bases than Linux distros, but they are real and out there.

[Balmipour]

Bash is quite everywhere, but many situations (like those damn crons) don't default to it. I'ts just important to be aware of it. I wouldn't have tried to use [[ ]] in my cron if I had been :)

[myfreeweb]

Note that if you install bash on FreeBSD, it won't be /bin/bash. It'll be /usr/local/bin/bash. The right way to call a non-standard interpreter like bash is #!/usr/bin/env bash.

[Ron Burk]

Some of the obsession with fastest is simply style. All else being equal, why not incorporate the more efficient code construct into your default style, especially if that construct also offers more readability? As far as portability, a good many tasks that bash is suited for are inherently non-portable. E.g., I need to run apt-get update if it's been more than X hours since it was last run. It is a great relief when one can leave portability off the already-too-long list of constraints for code.

[apaderno]

@alberge Bourne shell is not Bash (a.k.a. Bourne Again SHell).

[Rana Ghosh]

"But with [, you have to quote $b" For me, it would really help if you showed how to quote it. If $b evaluated to a*, would you just quote it like this: "$b"?

[Gordon]

Given autotools are not a POSIX shell, why would you ever expect [ to be defined as a POSIX shell function?

[Ami]

Because the autoconf script looks like a shell script, and it produces a shell script, and most shell commands operate inside it.

[JamesThomasMoon]

Google wrote "no pathname expansion ... takes place" yet [[ -d ~ ]] returns true (which implies ~ was expanded to /home/user). I think Google's should have been more precise in it's writing.

[Wlad]

Does this hold true "Everything what works in POSIX works in BASH but not vise versa." ?

[Ciro Santilli OurBigBook.com]

@Wlad Bash greatly extends POSIX, so any Bash extension won't be POSIX. The other way around I'm not 100%, but feels likely (except for when Bash extensions override a POSIX syntax, e,g. in posix [[ would presumably be a regular command too maybe). Related: askubuntu.com/questions/766270/…

[maoizm]

@JamesThomasMoon1979 this is tilde expansion, not a pathname expansio mentioned in google text

[Ciro Santilli OurBigBook.com]

@PauloPedroso obrigado! There's both beauty and horror in mastering legacy tech like Bash.

[Timo]

Why do you not write about > which also is redirection and greater than

[PePa]

The distinctive features of bash should be the reason to use them. If you're writing POSIX shell, fine, use whatever. I write bash scripts, and try to use all the sensible features of the language. Yes, they are not portable, but that is OK, Bash is not so difficult to get hold of. Particularly using [[ ]] is safer and more foolproof in many ways.

[PePa]

No need to have quotes around "filename" within [[ ]].

[siride]

It's funny to read all of the weird behaviors of [ compared to the quite sensible behaviors of [[ and come away with the recommendation to use [ based solely on portability (which is rarely a concern these days) and that people have to learn the "intricacies" of the bash version. It's more like you have to learn the absurd intricacies of the legacy version. The bash version does what you expect from most other programming languages.

[Grigory Entin]

While I share sentiments towards [[ being more "reasonable" in comparison to [, let me mention that we deal with them in the context of a regular shell, be it Bash or POSIX shell. So if we use Bash, it's not new that e.g. && does not have higher priority than ||, or that we should quote variable expansion, if we don't want word splitting and etc. [[, as opposed to [, changes the rules that are already/anyway there. From that perspective, having to account that extra [[ specific context, does not sound like a necessarily good thing to me.

[Masquue]

Stéphane Chazelas also mentioned in the comments of this answer some really peculiar behaviors when using =~ withing [[ (I'm horrified by those) which might be another reason that you want to avoid using =~ and [[ as this is the few [[ features without a native [ equivalent.