Writing simple shell scripts

Making a file a program

The first line is #!/bin/bash — the shebang — and it tells the kernel which interpreter to run the file with. Without it, the file is run by whatever happens to be interpreting, which is usually right until it is not. The file also needs execute permission (chmod +x), and it has to be found: a script in the current directory is run as ./script, because . is not in PATH.

Every command sets an exit status: 0 means success and anything else is failure, which is backwards from how truth is normally spelled and is the single thing to internalise here. $? holds the last status, exit N ends the script with a chosen one. && runs the next command only if the previous succeeded, || only if it failed.

That is what makes the one-line conditional in a cron entry work, and it is worth reading one against its neighbours. backup.sh || echo "backup failed" | mail -s "backup" root sends the mail only when backup.sh exited non-zero. With && instead, the mail goes out exactly when the backup SUCCEEDED, which is the inverted answer a question offers next to the right one. With a semicolon it goes out every night regardless. With a pipe it also goes out every night, because a pipe wires standard output to standard input and takes no interest in the exit status at all. Note also that the pipeline binds tighter than the list operators, so the echo and the mail together are the right-hand side of the ||.

Arguments, variables and tests

Positional parameters are $1 to $9 and beyond with ${10}; $0 is the script name, $# is how many arguments there were, $@ is all of them as separate words and $* as one. $$ is the script's own PID. Command substitution — $(command), or the older backticks — captures output into a variable. read NAME takes a line from standard input into a variable, which is how a script asks a question.

test EXPRESSION, spelled [ EXPRESSION ] with mandatory spaces inside the brackets, is how conditions are written. For files: -f is a regular file, -d a directory, -e exists at all, -r/-w/-x readable, writable, executable, -s non-empty. For strings: = and != compare, -z is empty and -n is non-empty. For numbers the operators are worded: -eq, -ne, -lt, -le, -gt, -ge, because < and > would be redirection. Quoting a variable in a test — [ "$x" = "y" ] — matters, since an unset variable would otherwise leave the bracket malformed.

Branching and looping

if CONDITION; then … elif … else … fi. case VALUE in pattern) … ;; esac matches against glob patterns and is the readable choice when there are several options. Both close with their own name reversed, which is a habit rather than a rule to memorise.

for VAR in LIST; do … done iterates over words — often a glob, a command substitution, or seq output. while CONDITION; do … done repeats while a command succeeds, and until is the same with the sense reversed. break leaves a loop and continue starts the next iteration.

The pieces that connect scripts to the rest of the system: xargs turns lines into arguments, and a script called by cron gets a minimal environment — no PATH you set in ~/.bashrc, no aliases — so scripts intended for cron use full paths and set what they need.

exec is the other one, and it does something a loop or a conditional cannot. Given a command, it does NOT fork: the shell overlays itself with the new program, which keeps the same PID and the same open file descriptors and inherits whatever the script had set up. So a wrapper that ends exec /usr/bin/myapp "$@" leaves no idle shell hanging around as a parent, myapp is what a service manager tracks, and signals reach it directly — at the cost that anything written after that line never runs, because there is no shell left to return to. Without exec the shell would fork, wait for the child and carry on to the cleanup. Given no command at all, exec is a different instruction again: exec >> /var/log/run.log 2>&1 applies those redirections to the current shell and execution continues normally.