Your First Script

A file of commands

A shell script is just a text file of commands, run one after another, as if you’d typed them ¹. Anything you can type at the prompt can go in a script, and a script can use variables, decisions, and loops like any programming language ².

Make a folder for practice and create hello:

me@linuxbox:~$ mkdir -p ~/shell-course/scripts && cd ~/shell-course/scripts
me@linuxbox:~/shell-course/scripts$ nano hello

#!/bin/bash
# hello: greet the user and show some facts about this machine.

echo "Hello, $USER."
echo "Today is $(date +%A), and this is $(hostname)."
echo "You have $(ls ~ | wc -l) items in your home folder."

Three steps make it a program ¹:

1. The shebang. The first line, #!/bin/bash, tells the system which program runs the file. Google’s style guide asks every executable script to start with exactly this line ³. (You’ll also see #!/usr/bin/env bash, which finds bash on PATH; it’s common for portability.)
2. Make it executable: chmod +x hello (module 3).
3. Run it with a path: ./hello. Or move it to ~/.local/bin and run it from anywhere by name (module 5).

me@linuxbox:~/shell-course/scripts$ chmod +x hello
me@linuxbox:~/shell-course/scripts$ ./hello
Hello, me.
Today is Monday, and this is linuxbox.
You have 9 items in your home folder.

Lines starting with # are comments. Start every script with a comment saying what it does and how to use it ³. Scripts that you run by name don’t need a .sh extension; libraries you source do ³.

Variables and constants

Variables work exactly as at the prompt (module 5): name=value, no spaces, and quote every expansion: "$name" ^{3 1}. Use "${name}" with braces when the name runs into other text.

Values that shouldn’t change are constants; mark them readonly and write them in capitals ³:

readonly BACKUP_DIR="$HOME/backups"
readonly KEEP_DAYS=30

Inside functions, declare variables local so they don’t leak into the rest of the script (lesson 3) ³.

Talking to the user

Printing. echo is fine for plain text. For anything with formatting, use printf, which takes a format string like other languages ⁴:

printf '%-12s %6.1f GB\n' "photos" 41.27

Reading input. read puts a line from standard input into a variable; -p shows a prompt, and -r keeps backslashes as typed ¹:

read -rp "Delete old downloads? [y/N] " answer

Errors go to standard error, not standard output ³. That way they show up on screen even when the script’s output is redirected to a file, and they don’t pollute data piped onward. A small function keeps it tidy:

die() {
    echo "$(basename "$0"): $*" >&2
    exit 1
}

>&2 sends echo’s output to stream 2 (module 4). $0 is the script’s own name.

Exit status. exit 0 for success, exit 1 (or another nonzero number) for failure, so &&, ||, and if work on your script like any command (module 6) ¹. A script that reaches its end exits with the status of its last command.

Safety settings

By default, bash keeps going after a command fails, happily expands misspelled variables to nothing, and ignores failures in the middle of pipelines. In a script that deletes or moves files, that’s dangerous. Put this right after the comment block ⁴:

set -euo pipefail

• -e: exit as soon as a command fails.
• -u: treat an unset variable as an error instead of expanding it to nothing. A typo like rm -rf "$BACKUPDIR/"* (for $BACKUP_DIR) would otherwise become rm -rf /*.
• -o pipefail: a pipeline fails if any part of it fails (module 6).

-e has blind spots by design: a failing command doesn’t stop the script if it’s the condition of an if or while, part of an && or || list (except the last command), or inverted with ! ⁴. That’s what lets you write [[ -d "$dir" ]] || die "...". Treat set -e as a safety net, not a substitute for checking the things that matter.

Checking and debugging

ShellCheck reads a script and points out bugs: unquoted variables, wrong test syntax, misspellings, commands that won’t do what you think, each with a code like SC2086 you can look up ⁵. Install it with sudo apt install shellcheck, run shellcheck hello, and fix what it reports. Make it a habit before you run anything that changes files.

To watch a script run, trace it ^{4 1}:

me@linuxbox:~/shell-course/scripts$ bash -x ./hello
+ echo 'Hello, me.'
Hello, me.
++ date +%A
...

Each + line is a command after expansion. You can also put set -x and set +x around just the part you’re debugging.

When to stop using bash

Shell scripts are perfect for gluing commands together. They get awkward as they grow: Google’s rule is that once a script passes about 100 lines, or its logic gets complicated, it should be rewritten in a more structured language, such as Python ³. Keep scripts short and focused.

Your turn

So

A script is a file of commands with a #!/bin/bash shebang, made executable with chmod +x and kept in ~/.local/bin. Quote variables, mark constants readonly, send errors to stderr with >&2, and exit nonzero on failure. Start with set -euo pipefail, check with ShellCheck, trace with bash -x, and switch languages when a script outgrows about 100 lines.