Advanced Bash: Input Validation, Error Handling, and Scheduling
Objective. Students will add input validation, exit codes, and cron scheduling to Bash scripts and verify correct behavior under failure conditions.
This lesson, its worked examples and its practice questions has not yet been verified by an industry-certified professional or by a certification or approval body. It is a study draft and may contain errors. Do not use it as instructions for work on a job site or on live equipment. Always follow your instructor, your supervising professional, and current official references and regulations.
VoTechWorks program approval and accreditation are still in progress. Credentials are issued only by the certifying bodies named in each program, after their own exams.
Why Robust Bash Scripts Matter
A script that works only under perfect conditions is not production-ready. Real servers encounter missing files, wrong arguments, occupied ports, and permission errors every day. A professional Bash script must detect those problems, report them clearly, and exit with a code that other tools can act on. This lesson adds three layers of reliability to your scripts: strict-mode settings, input validation with exit codes, and automated scheduling via cron.
Strict Mode: `set -euo pipefail`
Place this line near the top of every script you write in this program:
```bash
set -euo pipefail
```
- `-e` — Exit immediately if any command returns a non-zero status (unless the command is part of an `if`, `while`, or `||` construct).
- `-u` — Treat any reference to an undefined variable as an error and exit.
- `-o pipefail` — If any command in a pipeline fails, the whole pipeline returns a non-zero status instead of silently swallowing the error.
Without these options, a script can sail past a failed command and continue doing damage. Together they act like a safety net that stops execution as soon as something goes wrong.
Input Validation and the `usage()` Function
Users and automated callers will sometimes invoke your script incorrectly. Check required arguments at the top of the script and print helpful guidance when they are missing.
```bash
usage() {
echo "Usage: $0 <source_dir> <dest_dir>" >&2
exit 1
}
[[ $# -lt 2 ]] && usage
```
`>&2` redirects the message to standard error so it does not pollute standard output. The script then exits with code `1`, which signals a usage error to whatever called it.
Exit Codes
Every process exits with a number from 0 to 255. The universal convention:
| Code | Meaning |
|------|---------|
| 0 | Success |
| 1 | General or usage error |
| 2 | Misuse of shell built-in |
| Any non-zero | Something failed |
For scripts you write, define specific codes for each failure type and document them in a comment block at the top. For example:
```bash
```
The calling process (another script, a CI/CD pipeline, or cron) can read `$?` immediately after your script runs to decide what to do next.
Logging Errors to a File
A log file gives you a record of what happened and when. A minimal logging pattern:
```bash
LOGFILE="/var/log/deploy_check.log"
log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" >> "$LOGFILE"
}
log "INFO Script started"
if [[ ! -d "$SOURCE" ]]; then
log "ERROR Source directory $SOURCE not found"
exit 2
fi
log "INFO All checks passed"
```
Note on permissions: `/var/log/` is owned by root on most Linux systems. When running scripts as a non-root user, either use `sudo` carefully, choose a log path your user owns (such as `~/logs/`), or have an administrator pre-create the file with appropriate ownership. Never run a production script as root unless absolutely required — apply the principle of least privilege.
Scheduling with Cron
Cron is the standard Linux job scheduler. Each user has a personal crontab file edited with:
```bash
crontab -e
```
A crontab entry has five time fields followed by the command:
```
0 7 1-5 /home/user/deploy_check.sh >> /home/user/logs/deploy_check.log 2>&1
```
- `0 7` — at 7:00 a.m.
- ` ` — every month, every day of the month
- `1-5` — Monday through Friday (1 = Monday, 5 = Friday)
- `>> ... 2>&1` — append both stdout and stderr to the log
Always use absolute paths in crontab entries. Cron runs with a minimal environment and will not find scripts or interpreters through your interactive `PATH`. Verify entries with `crontab -l`.
Safety Points
- Least privilege: Run scripts with only the permissions they need. Avoid `sudo` inside scheduled scripts unless a specific command truly requires it.
- Log file permissions: Ensure log files are not world-writable (`chmod 640` is a reasonable starting point) to prevent unauthorized modification of audit records.
- Validate before destructive actions: Always confirm that source paths exist and destination directories are writable before moving or deleting data.
- Test in a non-production environment first: This lab uses student VMs precisely so mistakes affect only your own machine.
- Back up before modifying crontab: Cron errors that trigger repeatedly can fill disks or overload a server. Test the script manually before scheduling it.
Failure Simulation
The best way to verify error handling is to deliberately break things in a controlled way:
1. Remove the file your script expects — confirm a non-zero exit code and a log entry with a timestamp.
2. Bind a port with `nc -l 8080 &` — confirm the port-busy branch fires.
3. Call the script with no arguments — confirm `usage()` prints to stderr and exits with code 1.
Checking `echo $?` immediately after the script exits shows the exit code. Reading the log file with `tail -20 /path/to/logfile` confirms the timestamped entries.
Key terms9
Materials: Student VMs, crontab man page, Bash manual (set built-in section), previous deploy_check.sh script
Check: Instructor reviews crontab entry and runs script under each failure scenario; log entries and exit codes must be correct for all three scenarios — pass requires 3/3.
Practice check8
Answer each question, then check it. Nothing is recorded; this is your own practice.
