• Bash vulnerabilities
• The bash command hierarchy
• Preparing text editors for scripting
• Creating and executing scripts
• Debugging your scripts

For this book, I will beworking entirely on a Raspberry Pi 2 running Raspbian, a Linux distribution similar to Debian, and Ubuntu; although for you, the operating system you choose to work with is immaterial, in reality, as is the version of bash. The bash version I am using is 4.2.37(1). If you are using the OS X operating system, the default command line environment isbash.

To return the operating system being used, type the following command if it is installed:

$ lsb_release -a

The output from my system is shown in the following screenshot:

The easiest way to determine the version of bash that you are using is to print the value of a variable. The following command will display your bash version:

$ echo $BASH_VERSION

The following screenshot displays the output from my system:

In 2014, there was a well-publicized bug within bash that had been there for many years—the shell-shock bug. If your system is kept up-to-date, then it is not likely to be an issue but it is worth checking. The bug allows malicious code to be executed from within a malformed function. As a standard user, you can run the following code to test for the vulnerabilities on your system. This code comes from Red Hat and is not malicious but if you are unsure then please seek advice.

The following is the code from Red Hat to test for the vulnerability:

$ env 'x=() { :;}; echo vulnerable''BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

If your system is free from this first vulnerability the output should be as shown in the following screenshot:

To test for the last vulnerability from this bug, we can use the following test, which is again from Red Hat:

cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo

The output from a patched version of bash should look like the following screenshot:

If the output from either of these command lines is different, then your system may be vulnerable to shell-shock and I would update bash or at least take further advice from a security professional.

For example, if we type and enterls to list files, it will be reasonable to think that we were running the command. It is possible, but we will be running an alias often. Aliases exist in memory as a shortcut to commands or commands with options; these aliases are used before we even check for the file. The bash shell built-in commandtype can come to our aid here. Thetype command will display the type of command for a given word entered at the command line. The types of command is listed as follows:

This list is also a representative of the order in which they are searched. As we can see, it is not until the very end where we search for the executable filels.

The following command demonstrates the simple use type:

$ type lsls is aliased to `ls --color=auto'

We can extend this further to display all the matches for the given command:

$ type -a lsls is aliased to `ls --color=auto'ls is /bin/ls

If we need to just type in the output, we can use the-t option. This is useful when we need to test thecommand type from within a script and only need the type to be returned. This excludes the superfluous information; thus, making it easier for us humans to read. Consider the following command and output:

$ type -t lsalias

The output is clear and simple and just what a computer or script requires.

The built-intype can also be used to identify shell keywords such as if, case, function, and so on. The following command shows type being used against multiple arguments and types:

$ type ls quote pwd do id

The output of the command is shown in the following screenshot:

You can also see that thefunction definition is printed when we stumble across a function when usingtype.

Linux will check for executables in thePATH environment only when the full or relative path to the program is supplied. Ingeneral, the current directory is not searched unless it is in thePATH. It is possible to include our current directory within thePATH by adding the directory to thePATH variable. This is shown in the following code example:

$ export PATH=$PATH:.

This appends the current directory to the value of thePATH variable each item thePATH is separated using the colon. Now, yourPATH is updated to include the current working directory and each time you change directories, the scripts can be executed easily. In general, organizing scripts into a structured directory hierarchy is probably a great idea. Consider creating a subdirectory calledbin within your home directory and add the scripts into that folder. Adding$HOME/bin to yourPATH variable will enable you to find the scripts by name and without the file path.

The following command-line list will only create the directory, if it does not already exist:

$ test -d $HOME/bin || mkdir $HOME/bin

Although the above command-line list is not strictly necessary, it does show that scripting in bash is not limited to the actual script and we can use conditional statements and other syntax directly at the command line. From our viewpoint, we know that the preceding command will work whether you have thebin directory or not. The use of the$HOME variable ensures that the command will work without considering your current file system context.

As we work through the book, we will add scripts into the$HOME/bin directory so that they can be executed regardless of our working directory.

Editing the command line is often a must and is a part of my everyday life. Setting up common options that make life easier in the editor give us the reliability and consistency you need, a little likescripting itself. We will set some useful options in the vi or vim editor file,$HOME/.vimrc.

The options we set are detailed in the following list:

When these options are set, the$HOME/.vimrc file should look similar to this:

setshowmodenohlsearchsetautoindenttabstop=4setexpandtabsyntax on

The nano text edit is increasing in importance and it is the default editor in many systems. Personally, I don't like thenavigation or the lack of navigation features that it has. It can becustomized in the same way as vim. This time we will edit the$HOME/.nanorc file. Your edited file should look something like the following:

setautoindentsettabsize 4include /usr/share/nano/sh.nanorc

The last line enables syntax highlighting for shell scripts.

Graphical editors, such as gedit, can be configured using the preferences menu and are pretty straight forward.

Enabling tab spacing to be set to4 spaces and expanding tabs to spaces can be done using thePreference |Editor tab, as shown in the following screenshot:

Another very useful feature is found on thePreferences |Plugins tab. Here, we can enable theSnippets plugin that can be used to insert code samples. This is shown in the following screenshot:

For the rest of the book, we will be working on the command line in and in vim; feel free to use the editor that you work with best. We have now laid the foundations to create good scripts and although whitespace, tabs, and spaces in bash scripts are not significant; a well laid out file with consistent spacing is easy to read. When we look at Python later in the book, you will realize that in some languages the whitespace is significant to the language and it is better to adopt the good habits early.

As you know, it is almost obligatory to begin with ahello world script and we will not disappoint as far as this is concerned. We will begin by creating a new script$HOME/bin/hello1.sh. Thecontents of the file should read as in the following screenshot:

I am hoping that you haven't struggled with this too much; it is just three lines after all. I encourage you to run through the examples as you read to really help you instill the information with a good hands-on practice.

With the script saved in ourPATH environment, it still will not execute as a standalone script. We will have to assign and execute permissions for the file, as needed. For a simple test, we can run the file directly with bash. The following command shows you how to do this:

$ bash $HOME/bin/hello1.sh

We should be rewarded with theHello World text being displayed back on our screens. This is not a long-term solution, as we need to have the script in the$HOME/bin directory, specifically, to make the running of the script easy from any location without typing the full path. We need to add in the execute permissions as shown in the following code:

$ chmod +x $HOME/bin/hello1.sh

We should now be able to run the script simply, as shown in the following screenshot:

This script is simple butwe still have to know how to make use of the exit codes from scripts and other applications. The command-line list that we generated earlier while creating the$HOME/bin directory, is a good example of how we can use the exit code:

$ command1 || command 2

In the preceding example,command2 is executed only ifcommand1 fails in some way. To be specific,command2 will run ifcommand1 exits with a status code other than0.

Similarly, in the following extract:

$ command1 && command2

We will only executecommand2 ifcommand1 succeeds and issues an exit code of0.

To read the exit code from our script explicitly, we can view the$?variable, as shown in the following example:

$ hello1.sh$ echo $?

The expected output is0, as this is what we have added to the last line of the file and there is precious little else thatcan go wrong causing us to fail in reaching that line.

We can now createand execute a simple script but we need to consider the name a little. In this case,hello1.sh is going to be good enough and is unlikely to clash with anything else on the system. We should avoid using names that may clash with existing aliases, functions, keywords, and building commands, as well as, avoid names of programs already in use.

Adding thesh suffix to the file does not guarantee the name to be unique but in Linux, where we do not file extensions, the suffix is a part of the file name. This helps you to provide a unique identity to your script. Additionally, the suffix is used by the editor to help you identify the file for syntax highlighting. If you recall, we specifically added the syntax highlighting filesh.nanorc to the nano text editor. Each of these files is specific to a suffix and subsequent language.

Referring back to the command hierarchy within this chapter, we can use a type to determine the location and type of filehello.sh is:

$ type hello1.sh  #To determine the type and path$ type -a hello1.sh  #To print all commands found if the name is NOT unique$ type -t hello1.sh ~To print the simple type of the command

These commands and output can be seen in the following screenshot:

It is possible that we might need a little more substance in the script than a simple fixed message. Static message content does have its place but we can make this script much more useful by building some flexibility.

In this chapter, we will look atpositional parameters or arguments that we can supply to the script and in the next chapter we will see how we can make the script interactive and also prompt the user for input at runtime.

Running the script with arguments

We can run thescript with arguments, after all it's a free world and Linux promotes your freedom to do what you want to do with the code. However, if the script does not make use of the arguments, then they will be silently ignored. The following code shows the script running with a single argument:

$ hello1.shfred

The script will still run and will not produce an error. The output will not change either and will print hello world:

Argument Identifier	Description
$0	The name of the script itself and is often used in usage statements.
$1	Positional argument, the first argument passed to the script.
${10}	Where two or more digits are needed to represent the argument position. Brace brackets are used to delimit the variable name from any other content. Single value digits are expected.
$#	Argument count is especially useful when we need to set the amount of arguments needed for correct script execution.
$*	Refers to allarguments.

For the script to make use of the argument, we can change the script content a little. Let's first copy the script, add in the execute permissions, and then edit the newhello2.sh:

$ cp $HOME/bin/hello1.sh $HOME/bin/hello2.sh$ chmod +x $HOME/bin/hello2.sh

We need to edit thehello2.sh file to make use of the argument as it is passed at the command line. The following screenshot shows the simplest use of command line arguments allowing us now to have a custom message.

Run the script now, we can provide an argument as shown in the following:

$ hello2.sh fred

The output should now sayHello fred. If we do not provide an argument then the variable will be emptyand will just printHello. You can refer to the following screenshot to see the execution argument and output:

If we adjust the script to use$*, all the arguments will print. We will seeHello and then a list of all the supplied arguments. If we edit the script and replace theecho line as follows:

echo "Hello $*"

Executing the script with the following arguments:

$ hello2.shfredwilma  betty barney

Will result in the output shown in the following screenshot:

If we want to printHello <name>, each on separate lines, we will need to wait a little until we cover the looping structures. A for loop will work well to achieve this.

The importance of correct quotes

So far, we have used a simple double quoting mechanism to encase the strings that we want to use with echo.

In the first script, it does not matter if we use single or double quotes. Theecho "Hello World" will be exactly the same asecho 'Hello World'.

However, this will not be the case in the second script so it is very important to understand the quoting mechanisms available in bash.

As we have seen, using the double quotesecho "Hello $1" will result inHello fred or whatever the supplied value is. Whereas, if we use single quotesecho 'Hello $1' the printed output on the screen will beHello $1, where we see the variable name and not its value.

The idea of the quotes is to protect the special character such as a space between the two words; both quotes protect the space from being interpreted. The space is normally read as a default field, separated by the shell. In other words, all characters are read by the shell as literals with no special meaning. This has the knock on effect of the$ symbol printing its literal format rather than allowing bash to expand its value. The bash shell is prevented from expanding the variable's value, as it is protected by the single quotes.

This is where the double quote comes to our rescue. The double quote will protect all the characters except the$, allowing bash to expand the stored value.

If we ever need to use a literal$ within the quoted string along with variables that need to be expanded; we can use double quotes but escape the desired$ with the backslash (\). For example,echo "$USER earns \$4" would print asFred earns $4 if the current user was Fred.

Try the following examples at the command line using all quoting mechanisms. Feel free to up your hourly rate as required:

$ echo "$USER earns $4"$ echo '$USER earns $4'$ echo "$USER earns \$4"

The output is shown in the following screenshot:

The$0 variable represents the script name and this is often used in usage statements. As we are not yet looking at conditional statements, we will have the script name printed above the displayed name.

Edit your script so that it reads as the following complete code block for$HOME/bin/hello2.sh:

#!/bin/bashecho "You are using $0"echo "Hello $*"exit 0

The output from the command is shown in the following screenshot:

If we prefer not to print the path and only want the name of the script to show we can use thebasename command, which extracts the name from the path. Adjusting the script so that the second line now reads is as follows:

echo "You are using $(basename $0)"

The$(….) syntax is used to evaluate the output of the inner command. We first runbasename $0 and feed the result into an unnamed variable represented by the$.

The new output will appear as seen in the following screenshot:

It is possible to achieve the same results using back quotes, this is less easy to read but we have mentioned this asyou might have to understand and modify the scripts that have been written by others. The alternative to the$(….) syntax is shown in the following example:

echo "You are using 'basename $0'"

Please note that the characters used are back quotes andNOT single quotes. On UK and US keyboards, these are found in the top-left section next to the number1 key.

$ bash -v $HOME/bin/hello2.sh fred

$ bash -x $HOME/bin/hello2.sh fred