Lesson 10

In Module 4 you built the full “first script” workflow: you learned what makes a plain text file a shell script, how to edit it with vi, how to print output with echo, how to collect keyboard input with read, how to document your logic with comments, how to apply execute permissions with chmod, and finally how to run your script from a command line.

The big takeaway is that a script is both (1) a list of commands and (2) a repeatable tool. Once you can execute a script, you can refine it over time—adding prompts, validation, logging, and safer defaults—without retyping the same steps again and again.

1. Writing your first script: put frequently repeated commands into a file so they can be run reliably.
2. Interactive scripts: use echo to prompt and read to capture user input.
3. What makes a file a script: a valid interpreter line (shebang), valid commands, and executable permissions.
4. Editing: use vi (or another editor) to create plain-text files with UNIX line endings.
5. Comments: document intent (“why”), not the obvious mechanics (“what”).
6. Permissions: use ls -l to view permissions and chmod to add execute.
7. Execution: run scripts via ./scriptname (current directory) or by invoking a shell explicitly.

In the simplest case, a script is a list of system commands stored in a file. That alone saves time, but scripts become far more valuable when you add structure: variables, tests, exit codes, and clear messages.

Example 4-10.1: A minimal cleanup script (commands in a file)

# Cleanup
# Run as root, of course.
cd /var/log
cat /dev/null > messages
cat /dev/null > wtmp
echo "Log files cleaned up."

This is just a sequence of commands you could type manually. The advantage is repeatability: the script becomes a tool that you can update and standardize.

Example 4-10.2: Improved cleanup script (adds a proper header and variables)

#!/bin/bash
# Cleanup, version 2
# Run as root, of course.
# Insert code here to print error message and exit if not root.
LOG_DIR=/var/log

cd "$LOG_DIR"
cat /dev/null > messages
cat /dev/null > wtmp
echo "Logs cleaned up."
exit

Example 4-10.3: Enhanced cleanup script (checks privileges and validates input)

#!/bin/bash
# Cleanup, version 3
LOG_DIR=/var/log
ROOT_UID=0       # Only users with UID 0 have root privileges.
LINES=50         # Default number of lines saved.
E_XCD=86         # Can't change directory?
E_NOTROOT=87     # Non-root exit error.

if [ "$UID" -ne "$ROOT_UID" ]; then
  echo "Must be root to run this script."
  exit "$E_NOTROOT"
fi

if [ -n "$1" ]; then
  lines="$1"
else
  lines="$LINES"
fi

cd "$LOG_DIR" || exit "$E_XCD"

if [ "$(pwd)" != "$LOG_DIR" ]; then
  echo "Can't change to $LOG_DIR."
  exit "$E_XCD"
fi

Even if you don’t recognize every construct yet, notice the pattern: define variables, validate assumptions, and exit with a meaningful status code when something is wrong.

• Prefer portable shebangs when appropriate: on many systems /bin/sh is not Bash. If you require Bash features, use #!/usr/bin/env bash. If you want POSIX portability, write for sh.
• Run scripts safely: avoid putting “.” (current directory) in your PATH. Use ./script intentionally.
• Quote variables by default: "$VAR" prevents word-splitting and glob expansion surprises.
• Use linting: tools like shellcheck catch common bugs (quoting, test syntax, subshell issues).
• Understand permissions and umask: chmod +x enables execution, but your default umask influences what permissions new files start with.
• Security reminder: if your script handles encryption, avoid obsolete algorithms (e.g., DES). Prefer modern suites such as AES and SHA-256+ when you’re choosing tools and protocols.

Commands and components you used in this module include:

1. echo — print messages to the screen (STDOUT)
2. read — collect user input from the keyboard (STDIN)
3. chmod — set execute permissions on a script file
4. ls -l — view file permissions and ownership
5. #! — interpreter directive (shebang) at the top of the script
6. # — comment marker (ignored by the shell)

In the next module you will build on this foundation by working with variables and expanding scripts from “command lists” into maintainable programs.