Bash scripting

Introduction

This page is mostly foundation information. It's kinda boring but essential stuff that will help you to appreciate why and how certian things behave the way they do once we start playing about with the fun stuff (which I promise we'll do in the next section). Taking the time to read and understand the material in this section will make the other sections easier to digest so persevere and it'll be well worth your time.

So what are they exactly?

Think of a script for a play, or a movie, or a TV show. The script tells the actors what they should say and do. A script for a computer tells the computer what it should do or say. In the context of Bash scripts we are telling the Bash shell what it should do.
A Bash script is a plain text file which contains a series of commands. These commands are a mixture of commands we would normally type ouselves on the command line (such as ls or cp for example) and commands we could type on the command line but generally wouldn't (you'll discover these over the next few pages). An important point to remember though is:
Anything you can run normally on the command line can be put into a script and it will do exactly the same thing. Similarly, anything you can put into a script can also be run normally on the command line and it will do exactly the same thing.
You don't need to change anything. Just type the commands as you would normally and they will behave as they would normally. It's just that instead of typing them at the command line we are now entering them into a plain text file. In this sense, if you know how to do stuff at the command line then you already know a fair bit in terms of Bash scripting.
It is convention to give files that are Bash scripts an extension of .sh (myscript.sh for example). As you would be aware (and if you're not maybe you should consider reviewing our Linux Tutorial), Linux is an extensionless system so a script doesn't necessarily have to have this characteristic in order to work.

How do they work?

This is just a little bit of background knowledge. It's not necessary to understand this in order to write scripts but it can be useful to know once you start getting into more complex scripts (and scripts that call and rely on other scripts once you start getting really fancy).
In the realm of Linux (and computers in general) we have the concept of programs and processes. A program is a blob of binary data consisting of a series of instructions for the CPU and possibly other resources (images, sound files and such) organised into a package and typically stored on your hard disk. When we say we are running a program we are not really running the program but a copy of it which is called a process. What we do is copy those instructions and resources from the hard disk into working memory (or RAM). We also allocate a bit of space in RAM for the process to store variables (to hold temporary working data) and a few flags to allow the operating system (OS) to manage and track the process during it's execution.
Essentially a process is a running instance of a program.
There could be several processes representing the same program running in memory at the same time. For example I could have two terminals open and be running the command cp in both of them. In this case there would be two cp processes currently existing on the system. Once they are finished running the system then destroys them and there are no longer any processes representing the program cp.
When we are at the terminal we have a Bash process running in order to give us the Bash shell. If we start a script running it doesn't actually run in that process but instead starts a new process to run inside. We'll demonstrate this in the next section on variables and it's implications should become clearer. For the most part you don't need to worry too much about this phenomenon however.

How do we run them?

Running a Bash script is fairly easy. Another term you may come across is executing the script (which means the same thing). Before we can execute a script it must have the execute permission set (for safety reasons this persmission is generally not set by default). If you forget to grant this permission before running the script you'll just get an error message telling you as such and no harm will be done.

1. ./myscript.sh
2. bash: ./myscript.sh: Permission denied
3. ls -l myscript.sh
4. -rw-r--r-- 18 ryan users 4096 Feb 17 09:12 myscript.sh
5. chmod 755 myscript.sh
6. ls -l myscript.sh
7. -rwxr-xr-x 18 ryan users 4096 Feb 17 09:12 myscript.sh
8. ./myscript.sh
9. Hello World!

The shorthand 755 is often used for scripts as it allows you the owner to write or modify the script and for everyone to execute the script.

Here are the contents of myscript.sh

myscript.sh

1. #!/bin/bash
2. # A sample Bash script, by Ryan
4. echo Hello World!

Let's break it down:

• Line 1 - Is what's referred to as the shebang. See below for what this is.
• Line 2 - This is a comment. Anything after # is not executed. It is for our reference only.
• Line 4 - Is the command echo which will print a message to the screen. You can type this command yourself on the command line and it will behave exactly the same.
• The syntax highlighting is there only to make it easier to read and is not something you need to do in your own files (remember they are just plain text files).

Why the ./

You've possibly noticed that when we run a normal command (such as ls) we just type its name but when running the script above I put a ./ in front of it. When you just type a name on the command line Bash tries to find it in a series of directories stored in a variable called $PATH. We can see the current value of this variable using the command echo (you'll learn more about variables in the next section).

1. echo $PATH
2. /home/ryan/bin:/usr/local/bin:/usr/bin:/bin

The directories are separated by " : "
Bash only looks in those specific directories and doesn't consider sub directories or your current directory. It will look through those directories in order and execute the first instance of the program or script that it finds.
The $PATH variable is an individual user variable so each user on a system may set it to suit themselves.
This is done for a few different reasons.

• It allows us to have several different versions of a program installed. We can control which one gets executed based on where it sits in our $PATH.
• It allows for convenience. As you saw above, the first directory for myself is a bin directory in my home directory. This allows me to put my own scripts and programs there and then I can use them no matter where I am in the system by just typing their name. I could even create a script with the same name as a program (to act as a wrapper) if I wanted slightly different behaviour.
• It increases safety - For example a malicious user could create a script called ls which actually deletes everything in your home directory. You wouldn't want to inadvertantly run that script. But as long as it's not in your $PATH that won't happen.

If a program or script is not in one of the directories in your $PATH then you can run it by telling Bash where it should look to find it. You do so by including either an absolute or relative path in front of the program or script name. You'll remember that dot ( . ) is actually a reference to your current directory. Assuming this script is in my home directory I could also have run it by using an absolute path.

1. /home/ryan/myscript.sh
2. Hello World!

Variables

In this example we declare simple bash variable and print it on the screen ( stdout ) with echo command.

#!/bin/bash

 STRING="HELLO WORLD!!!"

 echo $STRING 

Bash string Variables in bash script

Your backup script and variables:

#!/bin/bash

 OF=myhome_directory_$(date +%Y%m%d).tar.gz

 tar -czf $OF /home/linuxconfig 

Bash backup Script with bash Variables

Global vs. Local variables

#!/bin/bash

#Define bash global variable

#This variable is global and can be used anywhere in this bash script

VAR="global variable"

function bash {

#Define bash local variable

#This variable is local to bash function only

local VAR="local variable"

echo $VAR

}

echo $VAR

bash

# Note the bash global variable did not change

# "local" is bash reserved word

echo $VAR

Global vs. Local Bash variables in bash script

Passing arguments to the bash script

#!/bin/bash

# use predefined variables to access passed arguments

#echo arguments to the shell

echo $1 $2 $3 ' -> echo $1 $2 $3'

# We can also store arguments from bash command line in special array

args=("$@")

#echo arguments to the shell

echo ${args[0]} ${args[1]} ${args[2]} ' -> args=("$@"); echo ${args[0]} ${args[1]} ${args[2]}'

#use $@ to print out all arguments at once

echo $@ ' -> echo $@'

# use $# variable to print out

# number of arguments passed to the bash script

echo Number of arguments passed: $# ' -> echo Number of arguments passed: $#' 

/arguments.sh Bash Scripting Tutorial 

Passing arguments to the bash script

Executing shell commands with bash

#!/bin/bash

# use backticks " ` ` " to execute shell command

echo `uname -o`

# executing bash command without backticks

echo uname -o 

Executing shell commands with bash

Reading User Input

#!/bin/bash

 

echo -e "Hi, please type the word: \c "

read  word

echo "The word you entered is: $word"

echo -e "Can you please enter two words? "

read word1 word2

echo "Here is your input: \"$word1\" \"$word2\""

echo -e "How do you feel about bash scripting? "

# read command now stores a reply into the default build-in variable $REPLY

read

echo "You said $REPLY, I'm glad to hear that! "

echo -e "What are your favorite colours ? "

# -a makes read command to read into an array

read -a colours

echo "My favorite colours are also ${colours[0]}, ${colours[1]} and ${colours[2]}:-)" 

Reading User Input with bash

#!/bin/bash

 

echo -e "Hi, please type the word: \c "

read  word

echo "The word you entered is: $word"

echo -e "Can you please enter two words? "

read word1 word2

echo "Here is your input: \"$word1\" \"$word2\""

echo -e "How do you feel about bash scripting? "

# read command now stores a reply into the default build-in variable $REPLY

read

echo "You said $REPLY, I'm glad to hear that! "

echo -e "What are your favorite colours ? "

# -a makes read command to read into an array

read -a colours

echo "My favorite colours are also ${colours[0]}, ${colours[1]} and ${colours[2]}:-)"