Bash Scripting: Variables, Loops, and Functions — Write Scripts That Survive Production

Every DevOps engineer has that one script. The one that runs fine in testing but deletes half the production logs at 2am because a variable was empty. Bash is unforgiving — a missing quote, an unset variable, a loop that silently skips errors. This isn't about syntax. It's about writing scripts that don't bite you. You're about to learn the patterns that separate a cron job that runs for years from the one that wakes you up at 3am. By the end, you'll write variables that don't leak, loops that fail fast, and functions that are actually reusable.

Variables: The Silent Killers

Variables seem harmless. Until an unquoted variable with a space in its value splits into two arguments, or an empty variable deletes the wrong directory. The problem is that bash, by default, treats missing variables as empty strings — not errors. That's why rm -rf /$important_dir becomes rm -rf / when $important_dir is unset. The fix: always quote expansions and use set -u to make unset variables fatal. Also, use ${var:-default} for safe defaults. In production, every variable expansion is a potential landmine.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

set -euo pipefail  # Exit on error, unset variable, pipe failure

log_dir="/var/log/myapp"
# Use default if variable is unset
archive_dir="${ARCHIVE_DIR:-/tmp/archive}"

# Always quote to preserve spaces and special chars
rm -rf "${log_dir:?}"  # :? fails if variable is empty or unset

# Array example: safe iteration
files=("file one.txt" "file two.txt")
for f in "${files[@]}"; do
    echo "Processing: $f"
done

Loops: Fail Fast or Fail Forever

Loops are where scripts go to die silently. A for loop over a glob that matches nothing runs once with the literal glob string. A while read loop that hits a permission error continues as if nothing happened. The fix: check that globs match before looping, and always check exit codes inside loops. Use shopt -s nullglob to make empty globs expand to nothing. For while read, add || break to stop on errors. And never pipe into while read — use process substitution to avoid subshell variable loss.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

set -euo pipefail

# Safe glob loop: nullglob prevents literal '*' when no files match
shopt -s nullglob
for config in /etc/myapp/*.conf; do
    echo "Processing $config"
    # Simulate processing; if it fails, break the loop
    process_file "$config" || { echo "Failed on $config"; break; }
done
shopt -u nullglob

# Safe while read with process substitution (no subshell)
count=0
while IFS= read -r line; do
    ((count++))
    echo "Line $count: $line"
done < <(grep 'ERROR' /var/log/app.log)
echo "Total errors: $count"

Functions: Encapsulate or Contaminate

Functions in bash are just commands — they run in the same shell unless you explicitly spawn a subshell. That means any variable you set inside a function leaks to the global scope unless you declare it local. The rule: every variable inside a function must be local. Also, functions should return meaningful exit codes (0 for success, non-zero for failure). Use return not exit — exit kills the entire script. And never use function keyword; it's non-portable. Just use name() { ... }.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

set -euo pipefail

# Good: local variables, return codes
process_log() {
    local logfile="$1"
    local errors
    errors=$(grep -c 'ERROR' "$logfile") || true  # grep returns 1 if no match
    if [[ "$errors" -gt 100 ]]; then
        echo "Too many errors: $errors"
        return 1
    fi
    echo "Errors: $errors"
    return 0
}

# Call function and check return
if process_log "/var/log/app.log"; then
    echo "Log OK"
else
    echo "Log check failed"
fi

When Not to Use Bash Functions

Bash functions are great for grouping commands, but they're terrible for complex logic. If your function has more than 20 lines, or uses arrays with complex manipulation, or needs to return structured data (like a list), switch to Python or a compiled language. Bash functions cannot return arrays — you have to echo and parse, which is fragile. Also, functions are slow in tight loops because each call forks a subshell (unless you use source). For performance-critical loops, inline the logic or use eval carefully.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

# Bad: function called in tight loop (slow)
slow_function() {
    echo "$(( $1 * 2 ))"
}
for i in {1..1000}; do
    result=$(slow_function $i)  # subshell each iteration
done

# Good: inline or use eval (if safe)
for i in {1..1000}; do
    result=$(( i * 2 ))
done

Debugging Bash Scripts in Production

When a script fails at 3am, you need fast diagnostics. First, enable set -x to trace every command. But be careful — it can leak secrets in logs. Use PS4='+ $BASH_SOURCE:$LINENO ' to get file and line numbers. Second, use trap to catch errors and print a stack trace. Third, log to syslog with logger instead of echo — it's timestamped and searchable. Never use echo for debugging in production; it mixes with normal output.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

set -euo pipefail

# Debug mode: trace with file and line
PS4='+ $BASH_SOURCE:$LINENO '
if [[ "${DEBUG:-}" == "true" ]]; then
    set -x
fi

# Error trap with stack trace
error_handler() {
    local line=$1
    local command=$2
    logger -p user.err "Error at line $line: $command"
    exit 1
}
trap 'error_handler $LINENO "$BASH_COMMAND"' ERR

# Simulate a command that might fail
cp /nonexistent/file /tmp/ || true  # trap won't fire because of || true

# Real failure
cp /nonexistent/file /tmp/  # this triggers the trap