3.3 Lesson 2

You will notice that our script has two possible states: either it prints "Hello <user>!" or it prints an error message. This is quite normal for many of our core utilities. Consider cat, which you are no doubt becoming very familiar with.

Let’s compare a successful use of cat with a situation where it fails. A reminder that our example above is a script called new_script.sh.

This command succeeds, and you will notice that the -n flag has also printed line numbers. These are very helpful when debugging scripts, but please note that they are not part of the script.

Now we are going to check the value of a new built-in variable $?. For now, just notice the output:

Now let’s consider a situation where cat will fail. First we will see an error message, and then check the value of $?.

The explanation for this behaviour is this: any execution of the cat utility will return an exit code. An exit code will tell us if the command succeeded, or experienced an error. An exit code of zero indicates that the command completed successfully. This is true for almost every Linux command that you work with. Any other exit code will indicate an error of some kind. The exit code of the last command to run will be stored in the variable $?.

Exit codes are usually not seen by human users, but they are very useful when writing scripts. Consider a script where we may be copying files to a remote network drive. There are many ways that the copy task may have failed: for example our local machine might not be connected to the network, or the remote drive might be full. By checking the exit code of our copy utility, we can alert the user to problems when running the script.

It is very good practice to implement exit codes, so we will do this now. We have two paths in our script, a success and a failure. Let’s use zero to indicate success, and one to indicate failure.

Notice that the echo command on line 15 was ignored entirely. Using exit will end the script immediately, so this line is never encountered.

So far our script can only handle a single username at a time. Any number of arguments besides one will cause an error. Let’s explore how we can make this script more versatile.

A user’s first instinct might be to use more positional variables such as $2, $3 and so on. Unfortunately, we can’t anticipate the number of arguments that a user might choose to use. To solve this issue, it will be helpful to introduce more built-in variables.

We will modify the logic of our script. Having zero arguments should cause an error, but any other number of arguments should be successful. This new script will be called friendly2.sh.

There are two built-in variables which contain all arguments passed to the script: $@ and $*. For the most part, both behave the same. Bash will parse the arguments, and separate each argument when it encounters a space between them. In effect, the contents of $@ look like this:

If you are familiar with other programming languages, you might recognize this type of variable as an array. Arrays in Bash can be created simply by putting space between elements like the variable FILES in script arraytest below:

It contains a list of many items. So far this isn’t very helpful, because we have not yet introduced any way of handling these items individually.

Let’s refer to the arraytest example shown before. If you recall, in this example we are specifying an array of our own called FILES. What we need is a way to “unpack” this variable and access each individual value, one after the other. To do this, we will use a structure called a for loop, which is present in all programming languages. There are two variables that we will refer to: one is the range, and the other is for the individual value that we are currently working on. This is the script in its entirety:

If you refer again to the friendly2.sh example above, you can see that we are working with a range of values contained within a single variable $@. For clarity’s sake, we will call the latter variable username. Our script now looks like this:

Remember that the variable that you define here can be named whatever you wish, and that all the lines inside do…​ done will be executing once for each element of the array. Let’s observe the output from our script:

Now let’s assume that we want to make our output seem a little more human. We want our greeting to be on one line.

A couple of notes:

Becomes this:

Let’s observe the output:

It’s possible that we want to verify all arguments that the user is entering. For example, perhaps we want to ensure that all names passed to friendly2.sh contain only letters, and any special characters or numbers will cause an error. To perform this error checking, we will use grep.

Recall that we can use regular expressions with grep.

The ^ and the $ indicate the beginning and end of the line respectively. The [A-Za-z] indicates a range of letters, upper or lower case. The * is a quantifier, and modifies our range of letters so that we are matching zero to many letters. In summary, our grep will succeed if the input is only letters, and fails otherwise.

The next thing to note is that grep is returning exit codes based on whether there was a match or not. A positive match returns 0, and a no match returns a 1. We can use this to test our arguments inside our script.

On line 12, we are redirecting standard output to /dev/null, which is a simple way to suppress it. We don’t want to see any output from the grep command, we only want to test its exit code, which happens on line 13. Notice also that we are using an exit code of 2 to indicate an invalid argument. It is generally good practice to use different exit codes to indicate different errors; in this way, a savvy user can use these exit codes to troubleshoot.