Lab 2. Shell scripting
Due: 2024-02-27 at 23:59
Shell scripts show up all over the place from programs on your computer to building software to running test suites as part of continuous integration. Learning to write (often short) Bash scripts can be a massive productivity boost as you can automate many tedious tasks. For example, if you find yourself needing to run a sequence of shell commands multiple times, a shell script is often the perfect tool. No more forgetting an argument or accidentally running the commands out of order. Write it once, run it many times.
In this lab, you will learn
- to write Bash shell scripts;
- how to run programs multiple times with different arguments;
- how to use tools to analyze your scripts for common errors.
Preliminaries
First, find a partner. You’re allowed to work by yourself, but I highly recommend working with a partner. Click on the assignment link. One partner should create a new team. The second partner should click the link and choose the appropriate team. (Please don’t choose the wrong team, there’s a maximum of two people and if you join the wrong one, you’ll prevent the correct person from joining.)
Once you have accepted the assignment and created/joined a team, you can clone the repository and begin working. But before you do, read the entire assignment and be sure to check out the expected coding style.
Be sure to ask any questions on Ed.
Coding style
For all of the shell scripts you write, I recommend you follow the Google Shell Style Guide. Look at the section on formatting. These rules are, in many ways, arbitrary. However, it’s good to stick to one style. The guide says to use two spaces to indent. Use whatever you’d like, but be consistent.
Once you open a shell script, the bottom of the window should show something like
Ln 1, Col 1 Spaces: 4 UTF-8 LF Shell Script
You can change the number of spaces by clicking on Space: 4, then Indent using spaces and then select 2 (to match the Shell Style Guide).
If you use NeoVim or Vim as your editor, you can include the line (called a modeline)
# vim: set sw=2 sts=2 ts=8 et:
at the bottom of each of your scripts to force Vim to indent by 2 spaces and to ensure that tabs will insert spaces (to match the Shell Style Guide). This requires “modeline” support to be enabled which is disabled by default. You can enable it by adding the line
set modeline
to your ~/.vimrc file, creating it if necessary.
You can also set options in your ~/.vimrc file, creating one if necessary.
For example, on clyde, I have the simple ~/.vimrc.
set background=dark
filetype plugin indent on
autocmd FileType sh setlocal shiftwidth=2 softtabstop=2 tabstop=8 expandtab
set modeline
The first line tells Vim to use colors suitable for a terminal with a dark background. The second line tells Vim to use file-type aware indenting. The third line tells Vim to set those options for shell script files. See the Vim wiki for more details. And the fourth enables modelines.
After you write the #!/bin/bash line at the top of your file (or a modeline
at the bottom), you’ll probably want to reopen the file so that Vim knows its
a bash file and turns on the appropriate syntax highlighting and indentation.
If you use emacs, you’re kind of on your own. Feel free to ask on Ed, search StackOverflow, and read the Emacs Wiki.
Same with Nano. This might be useful.
Run time errors and return values
For each of the parts below that ask you to print out a usage message or an
error message, this message should be printed to stderr. You can use code
like this to print a usage message.
echo "Usage: $0 arguments" >&2
Any errors should cause the script to exit with a nonzero value (1 is a pretty
good choice). Scripts that run successfully should exit with value 0. You can
use exit 1 to exit with the value 1.
Script warnings and errors
Make sure your scripts pass shellcheck without errors or warnings. If you
disable a particular warning, you must leave a comment giving a very good
reason why you did so.
Executable scripts
All of your scripts should start with the line
#!/bin/bash
and must be executable. Running $ chmod +x on each of the files before
adding them to Git is sufficient.
Script documentation
Each of your scripts should contain a comment at the top of the script (below
the #!/bin/bash line) that contains usage information plus a description of
what the program does.
Example.
#!/bin/bash
# Usage: shellcheckall [dir]
#
# The dir parameter should be the path to a directory. Shellcheckall will...
To get started, continue on to Part 1!