Anchor(Tests_And_Conditionals)

Tests and Conditionals

Sequential execution of applications is one thing, but to achieve a sort of logic in your scripts or your command line one-liners, you'll need variables and conditionals. Conditionals are used to make decisions which determine the execution flow of a script.


Anchor(Exit_Status)

1. Exit Status

Every application results in an exit code whenever it terminates. This exit code is used by whatever application started it to evaluate whether everything went OK. This exit code is like a return value from functions. It's an integer between 0 and 255 (inclusive). Convention dictates that we use 0 to denote success, and any other number to denote failure of some sort. The specific number is entirely application-specific, and is used to hint as to what exactly went wrong.

For example, the ping command sends ICMP packets over the network to a certain host. That host normally responds to this packet by sending the exact same one right back. This way, we can check whether we can communicate with a remote host. ping has a range of exit codes which can tell us what went wrong, if anything did:

From the ping manual:

The parameter ? shows us the exit code of the last foreground process that terminated. Let's play around a little with ping to see its exit codes:

    $ ping God
    ping: unknown host God
    $ echo $?
    2
    $ ping -c 1 -W 1 1.1.1.1
    PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
    --- 1.1.1.1 ping statistics ---
    1 packets transmitted, 0 received, 100% packet loss, time 0ms
    $ echo $?
    1


    rm file || { echo "Could not delete file!"; exit 1; }




Anchor(Control_Operators)

2. Control Operators

Now that we know what exit codes are, and that an exit code of '0' means the command's execution was successful, we'll learn to use this information. The easiest way of performing a certain action depending on the success of a previous command is through the use of 'control operators'. These operators are && and ||, which respectively represent a logical AND and a logical OR. These operators are used between two commands, and they are used to control whether the second command should be executed depending on the success of the first.

Let's put that theory in practice:

    $ mkdir d && cd d

This simple example has two commands, mkdir d and cd d. You could easily just use a semi-colon there to separate both commands and execute them sequentially; but we want something more. In the above example, ["BASH"] will execute mkdir d, then && will check the result of the mkdir application as it finishes. If the mkdir application resulted in a success (exit code 0), then && will execute the next command, cd d. If mkdir d failed, and returned a non-0 exit code, && will skip the next command, and we will stay in the current directory.

    $ echo "$PWD" && cd -

Another example:

    $ rm /etc/some_file.conf || echo "I couldn't remove the file!"
    rm: cannot remove `/etc/some_file.conf': No such file or directory
    I couldn't remove the file!

|| is much like &&, but it does the exact opposite. It only executes the next command if the first failed. As such, the message is only echoed if the rm command was unsuccessful.

You can make a sequence with these operators, but you have to be very careful when you do. Remember what exit code the operator is really going to be checking against! Here's an example that might cause confusion:

    $ false && true || echo "Riddle, riddle?"
    Riddle, riddle?
    $ true && false || echo "Riddle, riddle?"
    Riddle, riddle?

true is obviously always going to be successful. false is obviously always going to be unsuccessful. Can you guess why the echo statement is executed in both occasions?

The key to understanding how to sequence these operators properly is by evaluating exit codes from left to right.

In the first example, false is unsuccessful, so && does not execute the next command (which is true), but the next || gets a shot too. || still sees that the last exit code was that from false, and || executes the next command when the previous was unsuccessful. As a result, the echo statement is executed.

The same for the second statement again. true is successful, so the && executes the next statement. That is false; the last exit code now becomes unsuccessful. After that, || is evaluated, which sees the unsuccessful exit code from false and executes the echo statement.

It's all easy with trues and falses; but how about real commands?

    $ rm file && touch file || echo "File not found!"

All seems well with this piece of code, and when you test it, I'm sure you'll see that it actually does what it's supposed to. It tries to delete a file, and if it succeeds, it creates it again as a new and empty file; if something goes wrong we get the error message. What's the catch?

Perhaps you guessed, perhaps not, but here's a hint: Imagine the file system fills up (or some other disaster occurs) in between rm and the touch; the rm will succeed in deleting our file, but touch will fail to create it anew. As a result, we get a strange error message saying that the file wasn't found while we were actually trying to create it. What's up with that?

The next section will show a safer way to put both "AND" and "OR" conditions after a command.





Anchor(Conditional_Blocks)

3. Conditional Blocks

if is a shell builtin that executes a command, and checks that command's exit code to see whether its execution was successful. Depending on that exit code, if executes a specific block of code.

    $ if true
    > then echo "It was true."
    > else echo "It was false!"
    > fi
    It was true.

Here you see the basic outline of an if-statement. We start by calling if with the argument true. true is a built-in command that always ends successfully. if runs that command, and once the command is done, if checks the exit code. Since true always exits successfully, if continues to the then-block, and executes that code. Should the true application have failed somehow, and returned an unsuccessful exit code, the if statement would have skipped the then code, and executed the else code block instead.

There are commands that can help us a lot in doing conditional checks. They are [ (also named test) and [[. [ is a normal application that reads its arguments and does some checks with them. [[ is much like [, but it's special, and it offers far more versatility. Let's get practical:

    $ if [ a = b ]
    > then echo "a is the same as b."
    > else echo "a is not the same as b."
    > fi
    a is not the same as b.

if executes the command [ with the arguments 'a', '=', 'b' and ']'. [ uses these arguments to determine what must be checked. In this case, it checks whether the string 'a' is identical to the string 'b', and if this is the case, it will exit successfully. However, since we know this is not the case, [ will not exit successfully (its exit code will be 1). if sees that [ terminated unsuccessfully and executes the code in the else block.

Now, to see why [[ is so much more interesting and trustworthy than [, let us highlight some possible problems with [:

    $ if [ my dad = my dog ]
    > then echo "I have a problem."
    > fi
    -bash: [: too many arguments

Can you guess what caused the problem? BR [ was executed with the arguments 'my', 'dad', '=', 'my', 'dog' and ']'. [ doesn't understand what test it's supposed to execute, because it expects the second argument to be the operator. In our case, the operator is the third argument. Yet another reason why quotes are so terribly important. Whenever we type whitespace in bash that belongs together with the words before or after it, we need to quote the whole string:

    $ if [ 'my dad' = 'my dog' ]
    > then echo "I have a problem."
    > fi

This time, [ sees an operator (=) in the second argument and it can continue with its work. Now, this may be easy to see and avoid, but it gets just a little trickier when we put the strings in variables, rather than literally in the statement:

    $ dad='my dad'; dog='my dog'
    $ if [ $dad = $dog ]
    > then echo "I have a problem."
    > fi
    -bash: [: too many arguments

How did we mess up this time? BR Here's a hint: ["BASH"] takes our if-statement and expands all the parameters in it. The result is if [ my dad = my dog ]. Boom, game over.

Here's how it's supposed to look like:

    $ if [ "$dad" = "$dog" ]
    > then echo "I have a problem."
    > fi

To help us out a little, ["BASH"] introduced a new style of conditional test. Original as the ["BASH"] authors are, they called it [[. [[ is loaded with several very interesting features which are missing from [. One of them helps us in dealing with parameter expansions:

    $ if [[ $dad = $dog ]]
    > then echo "I have a problem."
    > fi
    $ if [[ I want $dad = I want $dog ]]
    > then echo "I want too much."
    > fi
    -bash: conditional binary operator expected
    -bash: syntax error near `want'

This time, $dad and $dog did not need quotes. Since [[ isn't an application (while [ is), but a shell keyword, it has special magical powers. It parses its arguments before they are expanded by bash and does the expansion itself, taking the result as a single argument, even if that result contains whitespace. However, be aware that simple strings still have to be quoted properly. [[ can't know whether your literal whitespace in the statement is intentional or not; so it splits it up just like ["BASH"] normally would. Let's fix our last example:

    $ if [[ "I want $dad" = "I want $dog" ]]
    > then echo "I want too much."
    > fi

You could also combine several if statements into one using elif instead of else; where each test indicates another possibility:

    $ name=lhunath
    $ if [[ $name = "George" ]]
    > then echo "Bonjour, $name!"
    > elif [[ $name = "Hans" ]]
    > then echo "Goeie dag, $name!"
    > elif [[ $name = "Jack" ]]
    > then echo "Good day, $name!"
    > else
    > echo "You're neither George, Hans or Jack.  Who the hell are you, $name?"
    > fi

Now that you've got a decent understanding of quoting issues that may arise, let's have a look at some of the other features that [ and [[ were blessed with:

You want some examples? Sure:

    $ test -e /etc/X11/xorg.conf && echo "Your Xorg is configured!"
    Your Xorg is configured!
    $ test -n "$HOME" && echo "Your homedir is set!"
    Your homedir is set!
    $ [[ boar != bear ]] && echo "Boars aren't bears!"
    Boars aren't bears!
    $ [[ boar != b?ar ]] && echo "Boars don't look like bears!"
    $ [[ $DISPLAY ]] && echo "Your DISPLAY variable is not empty, you probably have Xorg running."
    Your DISPLAY variable is not empty, you probably have Xorg running.
    $ [[ ! $DISPLAY ]] && echo "Your DISPLAY variable is not not empty, you probably don't have Xorg running."






Anchor(Conditional_Loops)

4. Conditional Loops

You've learned how to code some basic logic flow for your scripts. It's important that you understand a thing or two about keeping scripts healthy before we start introducing more complexity.

["BASH"] scripts, much like any other kind of scripts, should never be overrated. Although they have great potential once you fully understand the shell's features, they aren't always the right tool for the job. At the same time, when you make scripts, you should remember to keep them light, both in length and in complexity. Very long and/or very complex scripts are most often also very bad scripts. Those that aren't yet soon will be, because they are always very difficult to maintain and adapt/extend.

A technique that we can use to try and keep code length and complexity down is the loop. There are two kinds of loops. Using the correct kind of loop will help you keep your scripts readable and healthy.

["BASH"] supports while loops and for loops. The for loops can appear in three different forms. Here's a summary:

Let's put that in practice; here are some examples to illustrate the differences but also the similarities between the loops:

    $ while true
    > do echo "Infinite loop!"
    > done
    $ (( i=10 )); while (( i > 0 ))
    > do echo "$i empty cans of beer."
    > (( i-- ))
    > done
    $ for (( i=10; i > 0; i-- ))
    > do echo "$i empty cans of beer."
    > done
    $ for i in {10..0}
    > do echo "$i empty cans of beer."
    > done

The last three loops achieve exactly the same result, using different syntax. You'll encounter this many times in your shell scripting experience. There will nearly always be multiple approaches to solving a problem. The test of your skill soon won't be about solving a problem as much as about how best to solve it. You need to learn to pick the best angle of approach for the job. Usually, the main factors to keep into account will be the simplicity and flexibility of the resulting code. My personal favorite is the last of the examples. In that example I used Brace Expansion to generate the words; but there are other ways, too.

Let's take a closer look at that last example, because although it looks the easier of the two fors, it can often be the trickier, if you don't know exactly how it works.

As I mentioned before: for runs through a list of words and puts each in the variable, one at a time, then loops through the body with it. The tricky part is how ["BASH"] decides what the words are. Let me explain myself by expanding the braces from that previous example:

    $ for i in 10 9 8 7 6 5 4 3 2 1 0
    > do echo "$i empty cans of beer."
    > done

["BASH"] takes the characters between in and the end of the line, and splits them up into words. You shouldn't confuse the splitting that happens here with the splitting that happens with Commandline Arguments, even though they look exactly the same at first sight. Commandline arguments are split at spaces, tabs and newlines. The splitting in this for statement happens at spaces by default, but this default behaviour can be changed. The way for determines what delimiter to use for the splitting is by the contents of the IFS variable. IFS is an acronym for Internal Field Separator; and by default it contains a space, a tab and a newline. Since the space is one of the characters there, for uses it to split up the words in our sequence, and feeds each word to the variable i, one at a time.

As a result; be VERY careful not to make the following mistake:

    $ ls
    The best song in the world.mp3
    $ for file in $(ls *.mp3)
    > do rm "$file"
    > done
    rm: cannot remove `The': No such file or directory
    rm: cannot remove `best': No such file or directory
    rm: cannot remove `song': No such file or directory
    rm: cannot remove `in': No such file or directory
    rm: cannot remove `the': No such file or directory
    rm: cannot remove `world.mp3': No such file or directory

You should already know to quote the $file in the rm statement; but what's going wrong here? ["BASH"] expands the command substitution ($(ls *.mp3)), replaces it by its output, and as a result executes for file in The best song in the world.mp3. ["BASH"] splits that up into words by using spaces and tries to rm each word. Boom, you are dead.

You want to quote it, you say? Let's add another song:

    $ ls
    The best song in the world.mp3  The worst song in the world.mp3
    $ for file in "$(ls *.mp3)"
    > do rm "$file"
    > done
    rm: cannot remove `The best song in the world.mp3  The worst song in the world.mp3': No such file or directory

Quotes will indeed protect the whitespace in your filenames; but they will do more than that. The quotes will protect all the whitespace from the output of ls. There is no way ["BASH"] can know which parts of the output of ls represent filenames; it's not psychic. The output of ls is a simple string, and ["BASH"] treats it as such. The for puts the whole quoted output in i and runs the rm command with it. Damn, dead again.

So what do we do? As suggested earlier, globs are your best friend:

    $ for file in *.mp3
    > do rm "$file"
    > done

This time, ["BASH"] does know that it's dealing with filenames, and it does know what the filenames are, and as such it can split them up nicely. The result of expanding the glob is this: for file in "The best song in the world.mp3" "The worst song in the world.mp3". Problem resolved.

Let's talk about changing that delimiter. Say you've got yourself a nice cooking recipe, and you want to write a script that tells you how to use it. Sure, let's get right at it:

    $ recipe='2 c. all purpose flour
    > 6 tsp. baking powder
    > 2 eggs
    > 2 c. milk
    > 1/3 c. oil'
    $ for ingredient in $recipe
    > do echo "Take $ingredient; mix well."
    > done

Can you guess what the result will look like? I recommend you run the code if you can't and ponder the reason first. It will help you understand things.

Yes, as explained earlier, for splits its stuff up into words by using the delimiters from IFS.

To read the recipe correctly, we need to split it up by newlines alone, instead of by spaces and newlines. Here's how we do that:

    $ recipe='2 c. all purpose flour
    > 6 tsp. baking powder
    > 2 eggs
    > 2 c. milk
    > 1/3 c. oil'
    $ IFS=$'\n'
    $ for ingredient in $recipe
    > do echo "Take $ingredient; mix well."
    > done
    Take 2 c. all purpose flour; mix well.
    Take 6 tsp. baking powder; mix well.
    Take 2 eggs; mix well.
    Take 2 c. milk; mix well.
    Take 1/3 c. oil; mix well.

Beautiful.

Note: This delimiter is only used when the words consist of an expansion. Not when they're literal. Literal words are always split at spaces:

    $ PATH=/bin:/usr/bin
    $ IFS=:
    $ for i in $PATH
    > do echo "$i"
    > done
    /bin
    /usr/bin
    $ for i in $PATH:/usr/local/bin
    > do echo "$i"
    > done
    /bin
    /usr/bin
    /usr/local/bin
    $ for i in /bin:/usr/bin:/usr/local/bin
    > do echo "$i"
    > done
    /bin:/usr/bin:/usr/local/bin

Lets focus a little more on the while loop. It promises even more simplicity than this for loop, so long as you don't need any for specific features. The while loop is very interesting for its capacity of executing commands and basing the loop's progress on the result of them. Here are a few examples of how while loops are very often used:

    $ # The sweet machine; hand out sweets for a cute price.
    $ while read -p $'The sweet machine.\nInsert 20c and enter your name: ' name
    > do echo "The machine spits out three lollipops at $name."
    > done
    $ # Check your email every five minutes.
    $ while sleep 5m
    > do kmail --check
    > done
    $ # Wait for a host to come back online.
    $ while ! ping -c 1 -W 1 "$host"
    > do echo "$host is still unavailable."
    > done; echo -e "$host is available again!\a"

The until loop is barely ever used, if only because it is pretty much exactly the same as the while loop except for the fact that its command is not checked for an exit status of zero but for an exit status of non-zero. As a result, we could rewrite our last example using an until loop as such:

    $ # Wait for a host to come back online.
    $ until ping -c 1 -W 1 "$host"
    > do echo "$host is still unavailable."
    > done; echo -e "$host is available again!\a"





Anchor(Choices)

5. Choices

Sometimes you just want to built application logic depending on the content of a variable but you already know all of the possible choices of content the variable can contain. You no longer need if's two yes or no blocks, but you want a block of code for every possible choice of content a variable can have. You could obviously attempt to emulate this behaviour using several if-statements:

    $ if [[ $LANG = en* ]]
    > then echo "Hello!"; fi
    $ if [[ $LANG = fr* ]]
    > then echo "Salut!"; fi
    $ if [[ $LANG = de* ]]
    > then echo "Guten Tag!"; fi
    $ if [[ $LANG = nl* ]]
    > then echo "Hallo!"; fi
    $ if [[ $LANG = it* ]]
    > then echo "Ciao!"; fi

But let's say we like to actually make clean code, shall we? ["BASH"] provides a construct called case exactly for this kind of situation. A case construct basically enumerates several possible Glob Patterns and checks the content of your parameter against these:

    $ case $LANG in
    > en*) echo "Hello!" ;;
    > fr*) echo "Salut!" ;;
    > de*) echo "Guten Tag!" ;;
    > nl*) echo "Hallo!" ;;
    > it*) echo "Ciao!" ;;
    > *)   echo "I do not speak your language." ;;
    > esac

Each choice in a case statement starts with a pattern followed by a block of code that is to be executed if the parameter's content matches that pattern, which in turn is followed by two semi-colons. case stops matching patterns as soon as one was successful. Therefore, we can use the * pattern in the end to match any case that has not been caught by the other choices.

Another construct of choice is the select construct. This statement smells like a loop and is a convenience statement for generating a menu of choices that the user can choose from.

The user is presented by choices and asked to enter a number reflecting his choice. The code in the select block is then executed with a variable set to the choice the user made. If the user's choice was invalid, the variable is made empty:

    $ echo "Which of these does not belong in the group?"; \
    > select choice in Apples Pears Crisps Lemons Kiwis; do
    > if [[ $choice = Crisps ]]
    > then echo "Correct!  Crisps are not fruit."; break; fi
    > echo "Errr... no.  Try again."
    > done

The menu reappears so long as the break statement is not executed. In the example the break statement is only executed when the user makes the correct choice.

We can also use the PS3 variable to define the prompt the user replies on. Instead of showing the question before executing the select statement, we could choose to set the question as our prompt:

    $ PS3="Which of these does not belong in the group (#)? " \
    > select choice in Apples Pears Crisps Lemons Kiwis; do
    > if [[ $choice = Crisps ]]
    > then echo "Correct!  Crisps are not fruit."; break; fi
    > echo "Errr... no.  Try again."
    > done