Bash scripting fundamentals for Level 1

Bash scripts let you turn repeated terminal work into one reliable command. For a Level 1 technician, this is the first step from manual work to repeatable operations. You can use scripts for backups, account checks, service health checks, and cleanup jobs. The key point is not writing long code. The key point is writing small scripts that behave the same way every time.

What Bash scripting solves in daily Linux work

In a production system, copy and paste work often causes drift. One server gets one command, another server gets a slightly different command, and now troubleshooting takes longer. A Bash script removes that drift by storing the exact steps in one place.

For beginners, the gain is confidence. You run one script, read one log, and know what happened. For operators, the gain is control. Scripts can be versioned, reviewed, and scheduled by cron or systemd timers. That means fewer surprise differences between hosts.

Bash is already present on Debian 13.3, Ubuntu 24.04.3 LTS, Ubuntu 25.10, Fedora 43, and RHEL 10.1. RHEL 9.7 environments use the same Bash approach, so the habits in this article transfer directly.

Start with a safe script template

Many script failures come from weak defaults. A safer template gives better failure behavior from day one. Use this as your base:

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

LOG_FILE="/var/log/level1-audit.log"

log() {
  local msg="$1"
  printf '%s %s\n' "$(date '+%F %T')" "$msg" | tee -a "$LOG_FILE"
}

if [[ "${EUID}" -ne 0 ]]; then
  echo "Run as root because /var/log needs write access."
  exit 1
fi

log "Script started"

set -euo pipefail changes behavior in useful ways. -e stops on command errors, -u stops on unset variables, and pipefail makes a pipeline fail if any command inside it fails. Without these options, broken commands can pass quietly and create bad data later.

IFS=$'\n\t' reduces word-splitting problems when file names include spaces. This matters in real environments because users and tools do create paths like /srv/app data.

Variables, quoting, and input validation

Quoting is one of the most important Bash habits. Unquoted variables can split into multiple words or expand wildcards. That can target the wrong files and create hard-to-find damage.

#!/usr/bin/env bash
set -euo pipefail

source_dir="/srv/app data"
backup_dir="/backups/app"
timestamp="$(date '+%Y%m%d_%H%M%S')"
archive="${backup_dir}/app_${timestamp}.tar.gz"

mkdir -p "$backup_dir"
tar -czf "$archive" "$source_dir"
echo "Created $archive"

read -r -p "Check user account: " user_name
if id "$user_name" >/dev/null 2>&1; then
  echo "User exists"
else
  echo "User not found" >&2
  exit 2
fi

Notice that every variable used as a path is quoted. That single habit prevents a large class of production mistakes. Also, user input is validated with id before we continue. Never trust input from prompts, files, or API output until you validate it.

Control flow, functions, and exit codes

Functions make scripts easier to read and easier to debug. Exit codes let your scheduler or monitoring tool detect failure correctly. Use clear return values, then exit with a non-zero code when the script cannot continue safely.

#!/usr/bin/env bash
set -euo pipefail

check_unit() {
  local unit="$1"
  if systemctl is-active --quiet "$unit"; then
    echo "$unit is active"
    return 0
  fi

  echo "$unit is not active" >&2
  return 2
}

if ! check_unit "sshd.service"; then
  logger -t level1-script "Service check failed for sshd.service"
  exit 2
fi

echo "All checks passed"

This pattern is practical in cron, systemd timers, and CI jobs. If the script exits 0, automation marks success. If it exits non-zero, alerts can trigger. Beginners often print an error message but still exit 0, which hides failures from monitoring.

Production-safe file handling and concurrency

Two copies of the same cleanup script running at once can remove files unexpectedly or rotate logs twice. Add a lock with flock so only one run proceeds. Also, clean temporary files with a trap so interrupted runs do not leave stale state.

#!/usr/bin/env bash
set -euo pipefail

tmp_list="/tmp/cache-cleanup.list"
lock_file="/run/lock/cache-cleanup.lock"

cleanup() {
  rm -f "$tmp_list"
}
trap cleanup EXIT

exec 9>"$lock_file"
if ! flock -n 9; then
  echo "Another cleanup run is already in progress"
  exit 0
fi

find /var/cache/myapp -type f -name '*.tmp' -mtime +7 -print >"$tmp_list"
while IFS= read -r file; do
  rm -f "$file"
done <"$tmp_list"

echo "Cleanup completed"

Operational consequence: without the lock, overlapping runs can generate noisy failures and partial cleanup. Without the trap, old temp files can be reused by mistake in the next run. Both issues show up often in shared servers.

Compatibility notes for Debian, Ubuntu, Fedora, and RHEL

Most scripts above work unchanged on Debian 13.3, Ubuntu 24.04.3 LTS, Ubuntu 25.10, Fedora 43, RHEL 10.1, and RHEL 9.7. Still, check these points before deployment:

• /bin/sh is not always Bash: Debian and Ubuntu use dash for /bin/sh. If your script needs Bash features like arrays or [[ ]], use #!/usr/bin/env bash.
• Service names can differ: package naming and default unit names vary. Verify units with systemctl list-unit-files | grep -E 'ssh|cron|sshd'.
• Tool availability: flock is usually available through util-linux, but minimal images may omit parts of the package set. Confirm in base images before rollout.
• SELinux context on Fedora and RHEL: scripts writing under protected paths may fail even as root if context is wrong. Check logs with journalctl -xe and audit messages before disabling protections.

Summary

Level 1 Bash scripting is about safe repetition: strict options, quoted variables, validated input, clear exit codes, and lock-protected jobs. These habits reduce real failures in production and make your work easier to review. Start with short scripts, test them on one host, then roll out in stages across Debian, Ubuntu, Fedora, and RHEL systems.