OPS145 Lab 9 Newversion

Bash scripting

Bash is the shell you've been using in this course to run Linux commands. Bash is also a programming language. It's a special purpose programming language, not something you would write a graphical application in. What you do in a bash script is essentially the exact equivalent of what you would run at a terminal prompt - except you can run all your commands at once, instead of one at a time.

A bash script is a plain text file. The bash programming language is interpreted (as opposed to compiled) - meaning the code you write doesn't need to be compiled before you can execute it.

Setup

The setup for writing a bash script is minimal. You'll need to:

1. Create the script in a plain text editor: either graphical or on the command line. Usually you save it with a .sh extension, though technically you don't have to.
2. Make sure you (and anyone else you want to allow to execute the script) have read and execute permissions for the file.
3. Add a shebang line at the top.

Permissions

Since bash scripts are interpreted (rather than executed outright): you can't actually execute a bash file. In order to execute the commands in a bash script: they need to be read, and interpreted, and executed, by the bash program.

That's why just giving a script execute permissions may not be enough to run it. You need to give yourself read permission, so that the bash program can read your script and execute it.

In fact you don't even need execute permissions to run a bash script. You can run bash, and give it the name of the script as the first argument.

Shebang line

Because bash scripts are interpreted, and extensions are mostly ignored in Linux: the shell you're using to execute your script needs to know what kind of script it is. There are many interpreted programming languages. If you don't make it clear what language your script is written in: there's a chance it will be misinterpreted.

A shebang line for a bash script looks like this:

#!/bin/bash

It has the be the first line in your script.

Anything following this line is regular bash.

hello.sh

Decide for yourself whether you can handle the bash learning in this lab while using vi. If you feel that's too hard: you can use a graphical text editor.

• Create the lab9 directory inside your home directory.
• Open a text editor and save an empty file into ~/lab9/hello.sh
• Add the shebang line at the top
• Look at the permissions for your file in a terminal. You'll find that by default you have read and write permissions, but not execute permissions. Give yourself execute permissions using one of these two commands

  chmod a+x hello.sh # Add execute permissions for everyone, or:
  chmod 755 hello.sh # Set permissions to exactly this
  

• Run the script by specifying an absolute path, a relative-to-home path, or if your PWD is right: you can use the . special character as a shortcut:

  /home/yourusername/lab9/hello.sh # Run first.sh using an absolute path
  ~/lab9/hello.sh # Run first.sh relative-to-home path
  ./hello.sh # Run first.sh from the PWD
  

Your script doesn't do anything yet: but if you get any errors: the script might be in the wrong place, or it might have the wrong permisions, or you're not executing it correctly.

echo

echo is an interesting command. Initially it may appear to do nothing of use, but with better understanding of how programming works it will make a lot more sense.

The echo command prints some output (via STDOUT) - whatever output you tell it to print.

For example: if you run this in a terminal:

echo Hello

it will print the word Hello. If you give echo multiple arguments: it will print them all, with one space in between each of them:

echo Hello    there # Note the multiple spaces

Remember that in bash the arguments for a command are whitespace-separated. So it doesn't matter how many spaces you put between arguments to echo: they are still interpreted as separate arguments. If you want to include multiple words and all the spacing between them in echo's output: combine them all into a single argument by enclosing the entire string of text into quotes:

echo "Hello    there" # Note the multiple spaces

The echo command can be used for more complicated things, but this is all we need for this lab.

• Add a line to your shell script so that when you run the script: it will print: "Hello. I will now do a bunch of stuff". It should look like this when you run it:

One of the main reasons shell scripts are exceptionally useful is that once you get your script to work: you don't need to worry about typos, command syntax, or even remembering how exactly the commands work.

The other big reason is: you don't have to retype your commands every time you want to run them.

This simple echo program is a great example of that. You can already see that typing the command to run the script is much shorter than the one echo line inside the script. Obviously the longer the script: the greater the probability you will make mistakes, and the more you'd need to type when you wanted those commands executed.

date

Another very simple command is date.

• Run date in a terminal. It will print the current date and time.

Using arguments you can change the format of the output, add or remove parts that you want or don't want to see. We won't need to do that but if you're curious: you can look at the man page for date, under the FORMAT section.

• Modify your script so that its output looks like this (except with the current date, don't hard-code the 25th of march in your script):

Re-running a script

A script is usually meant to execute unattended. Ideally your script will account for the most common variability in the environment.

For example: if you mean to create a directory in a script, and you run the script a second time: the script should not cause errors the second time because the directory was already created the first time. You should decide when you build the script how to deal with this possibility.

As an example: let's start with a script like this:

#!/bin/bash

mkdir ~/lab9/temp/

• Save that code as ~/lab9/lab9.sh and give it execute permissions.
• Run lab9.sh twice.
• Note that the first time you run it: it creates the temp directory. The second time you run it: you get an error.

Depending on the circumstances you might want to ignore the error, or make sure the directory is deleted before you attempt to create it, or you might actually want to get an error.

• In our case let's say we want a brand new, empty, temp directory created every time the script runs. To ensure that happens: delete the directory before you create it:

  #!/bin/bash
  
  rm -r ~/lab9/temp/
  mkdir ~/lab9/temp/
  

• Now you can run the script as many times as you want, and every time you will end up an empty temp directory.

This script still has some potential problems, but all of them are dealt with in the same way:

1. Anticipate what could go wrong
2. Structure your code to do something you want under different circumstances

lab3-9.sh

We're going to write a script which will do all the work for lab 3.

Also

• temp files
• script2:
  • delete directory
  • create directory tree
• script3 extended from script2:
  • fill up tree with files
  • create tarball
• 
  

Submit evidence of your work

After you finish the lab: run the following commands to submit your work:

cd ~
wget http://ops345.ca/check/ops145-lab9-check.sh # Download the check script
chmod 700 ops145-lab9-check.sh # Make the downloaded file executable
./ops145-lab9-check.sh # Run the check script

If it says "Your lab9 has been submitted": make a screenshot, and you're done. If it gives you any warnings or errors: you have to fix them and try the ./ops145-lab7-check.sh command again.