How to declare and use Boolean variables in a shell script?

You can use the following code for declaring and using boolean variables in a shell script:

Revised Answer

# something interesting...
if [ "$the_world_is_flat" = true ] ; then
    echo 'Be careful not to fall off!'

Original Answer

# something interesting...
if $the_world_is_flat ; then
    echo 'Be careful not to fall off!'

How to declare and use boolean variables in a shell script? Detailed answer:

There seems to be some misunderstanding here about the Bash builtin true, and more specifically, about how Bash expands and interprets expressions inside brackets.

The code in first answer has absolutely nothing to do with the Bash builtin true, nor /bin/true, nor any other flavor of the true command. In this case, true is nothing more than a simple character string, and no call to the true command/builtin is ever made, neither by the variable assignment, nor by the evaluation of the conditional expression.

The following code is functionally identical to the code in the miku’s answer:

if [ "$the_world_is_flat" = yeah ]; then
    echo 'Be careful not to fall off!'

The only difference here is that the four characters being compared are ‘y’, ‘e’, ‘a’, and ‘h’ instead of ‘t’, ‘r’, ‘u’, and ‘e’. That’s it. There’s no attempt made to call a command or builtin named yeah, nor is there (in miku’s example) any sort of special handling going on when Bash parses the token true. It’s just a string, and a completely arbitrary one at that.

Update (2014-02-19): After following the link in miku’s answer, now I see where some of the confusion is coming from. Miku’s answer uses single brackets, but the code snippet he links to does not use brackets. It’s just:

if $the_world_is_flat; then
  echo 'Be careful not to fall off!'

Both code snippets will behave the same way, but the brackets completely change what’s going on under the hood.

Here’s what Bash is doing in each case:

No brackets:

  1. Expand the variable $the_world_is_flat to the string "true".
  2. Attempt to parse the string "true" as a command.
  3. Find and run the true command (either a builtin or /bin/true, depending on the Bash version).
  4. Compare the exit code of the true command (which is always 0) with 0. Recall that in most shells, an exit code of 0 indicates success and anything else indicates failure.
  5. Since the exit code was 0 (success), execute the if statement’s then clause


  1. Expand the variable $the_world_is_flat to the string "true".
  2. Parse the now-fully-expanded conditional expression, which is of the form string1 = string2. The = operator is bash’s string comparison operator. So…
  3. Do a string comparison on "true" and "true".
  4. Yep, the two strings were the same, so the value of the conditional is true.
  5. Execute the if statement’s then clause.

The no-brackets code works, because the true command returns an exit code of 0, which indicates success. The bracketed code works, because the value of $the_world_is_flat is identical to the string literal true on the right side of the =.

Just to drive the point home, consider the following two snippets of code:

This code (if run with root privileges) will reboot your computer:

if $var; then
  echo 'Muahahaha! You are going down!'

This code just prints “Nice try.” The reboot command is not called.

if [ $var ]; then
  echo 'Nice try.'

Update (2014-04-14) To answer the question in the comments regarding the difference between = and ==: AFAIK, there is no difference. The == operator is a Bash-specific synonym for =, and as far as I’ve seen, they work exactly the same in all contexts.

Note, however, that I’m specifically talking about the = and == string comparison operators used in either [ ] or [[ ]] tests. I’m not suggesting that = and == are interchangeable everywhere in bash.

For example, you obviously can’t do variable assignment with ==, such as var=="foo" (well technically you can do this, but the value of var will be "=foo", because Bash isn’t seeing an == operator here, it’s seeing an = (assignment) operator, followed by the literal value ="foo", which just becomes "=foo").

Also, although = and == are interchangeable, you should keep in mind that how those tests work does depend on whether you’re using it inside [ ] or [[ ]], and also on whether or not the operands are quoted.

Are there any boolean variables in Bash?

Long story short:

There are no Booleans in Bash

The true and false commands

Bash does have Boolean expressions in terms of comparison and conditions. That said, what you can declare and compare in Bash are strings and numbers. That’s it.

Wherever you see true or false in Bash, it’s either a string or a command/builtin which is only used for its exit code.

This syntax…

if true; then ...

is essentially…

if COMMAND; then ...

where the command is true. The condition is true whenever the command returns exit code 0. true and false are Bash builtins and sometimes also standalone programs that do nothing but returning the corresponding exit code.

Conditions in

When using square brackets or the test command, you rely on the exit code of that construct. Keep in mind that [ ] and [[ ]] are also just commands/builtins like any other. So …

if [[ 1 == 1 ]]; then echo yes; fi

corresponds to

if COMMAND; then echo yes; fi

and the COMMAND here is [[ with the parameters 1 == 1 ]]

The construct is just syntactic sugar. You can always just run the commands separated by a double ampersand for the same effect:

[[ 1 == 1 ]] && echo yes

When using true and false in these testing constructs you are actually only passing the string "true" or "false" to the testing command. Here is an example:

Believe it or not but those conditions are all yielding the same result:

if [[ false ]]; then ...
if [[ "false" ]]; then ...
if [[ true ]]; then ...
if [[ "true" ]]; then ...

TL;DR; always compare against strings or numbers

To make this clear to future readers, I would recommend always using quotes around true and false:


if [[ "${var}" == "true" ]]; then ...
if [[ "${var}" == "false" ]]; then ...
if [[ "${var}" == "yes" ]]; then ...
if [[ "${var}" == "USE_FEATURE_X" ]]; then ...
if [[ -n "${var:-}" ]]; then echo "var is not empty" ...


# Always use double square brackets in bash!
if [ ... ]; then ...
# This is not as clear or searchable as -n
if [[ "${var}" ]]; then ...
# Creates impression of Booleans
if [[ "${var}" != true ]]; then ...
# `-eq` is for numbers and doesn't read as easy as `==`
if [[ "${var}" -eq "true" ]]; then ...


# Creates impression of Booleans.
# It can be used for strict checking of dangerous operations.
# This condition is false for anything but the literal string "true".
if [[ "${var}" != "true" ]]; then ... 

Answer #4:

Long ago, when all we had was sh, Booleans where handled by relying on a convention of the test program where test returns a false exit status if run without any arguments.

This allows one to think of a variable that is unset as false and variable set to any value as true. Today, test is a builtin to Bash and is commonly known by its one-character alias [ (or an executable to use in shells lacking it, as dolmen notes):

FLAG="up or <set>"

if [ "$FLAG" ] ; then
    echo 'Is true'
    echo 'Is false'

# Unset FLAG
#    also works

if [ "$FLAG" ] ; then
    echo 'Continues true'
    echo 'Turned false'

Because of quoting conventions, script writers prefer to use the compound command [[ that mimics test, but has a nicer syntax: variables with spaces do not need to be quoted; one can use && and || as logical operators with weird precedence, and there are no POSIX limitations on the number of terms.

For example, to determine if FLAG is set and COUNT is a number greater than 1:

FLAG="u p"

if [[ $FLAG  && $COUNT -gt '1' ]] ; then
    echo 'Flag up, count bigger than 1'
    echo 'Nope'

This stuff can get confusing when spaces, zero-length strings, and null variables are all needed and also when your script needs to work with several shells.

Alternate findings:

My findings and suggestion differ a bit from the other posts. I found that I could use “booleans” basically as one would in any “regular” language, without the “hoop jumping” suggested…

There isn’t any need for [] or explicit string comparisons… I tried multiple Linux distributions. I tested Bash, Dash, and BusyBox. The results were always the same. I’m not sure what the original top voted posts are talking about. Maybe times have changed and that’s all there is to it?

If you set a variable to true, it subsequently evaluates as an “affirmative” within a conditional. Set it to false, and it evaluates to a “negative”. Very straightforward! The only caveat, is that an undefined variable also evaluates like true! It would be nice if it did the opposite (as it would in most languages), but that’s the trick – you just need to explicitly initialize your booleans to true or false.

Why does it work this way? That answer is two fold. A) true/false in a shell really means “no error” vs “error” (i.e. 0 vs anything else). B) true/false are not values – but rather statements in shell scripting! Regarding the second point, executing true or false on a line by itself sets the return value for the block you’re in to that value, i.e. false is a declaration of “error encountered”, where true “clears” that. Using it with an assignment to a variable “returns” that into the variable. An undefined variable evaluates like true in a conditional because that equally represents 0 or “no error encountered”.

See the example Bash lines and results below. Test it yourself if you want to confirm…


# Not yet defined...
echo "when set to ${myBool}"
if ${myBool}; then echo "it evaluates to true"; else echo "it evaluates to false"; fi;

echo "when set to ${myBool}"
if ${myBool}; then echo "it evaluates to true"; else echo "it evaluates to false"; fi;

echo "when set to ${myBool}"
if ${myBool}; then echo "it evaluates to true"; else echo "it evaluates to false"; fi;


when set to
it evaluates to true
when set to true
it evaluates to true
when set to false
it evaluates to false

Hope you learned something from this post.

Follow Programming Articles for more!

About ᴾᴿᴼᵍʳᵃᵐᵐᵉʳ

Linux and Python enthusiast, in love with open source since 2014, Writer at, India.

View all posts by ᴾᴿᴼᵍʳᵃᵐᵐᵉʳ →