Understanding Basic Bash Scripts

A Systematic Approach to Reading Scripts

When you first open a script, it can look like a confusing wall of text. The key is to break it down methodically. Here's a five-step process you can use every time:

1. Start at the Top: Look for the shebang (#!/bin/bash) to confirm the interpreter. Read any comments (#) at the beginning; they often explain the script's purpose, author, and usage.
2. Identify Inputs: How does the script get its data?
   • Hardcoded variables: VARIABLE="some_value"
   • Command-line arguments: $1, $2, $@
   • User input: read VARIABLE_NAME
3. Trace the Logic Flow: Identify the main control structures.
   • Conditionals: What decisions does the script make (if, else)? What conditions ([ -f file ], [ "$VAR" == "val" ]) does it test?
   • Loops: What actions are being repeated (for, while)? What list or condition controls the repetition?
4. Understand the Core Commands: Inside the loops and conditionals, what are the key commands doing the actual work? (e.g., grep, find, ping, cp, mkdir).
5. Follow the Output: Where does the information go?
   • Printed to the screen (echo)?
   • Saved to a file (> report.txt or >> log.txt)?
   • Discarded (> /dev/null)?

Let's apply this method to a few examples.

Example 1: Conditionals and Arguments

Take a look at this image showing a simple script and its execution.

Let's analyze it with our five-step process:

1. Top: No shebang or comments are visible, but the context implies a Bash script.
2. Inputs: It uses $1, the first command-line argument.
3. Logic: An if-else statement. The condition is [[ -z $1 ]]. The -z operator tests if a string is empty. So, the script is asking, "Was the first command-line argument empty?"
4. Core Commands: The only command is echo, which prints text to the screen.
5. Output: It prints "No parameter passed." if the condition is true (no argument given) and "Parameter passed = ..." if the condition is false (an argument was provided).

Interpretation: This script checks if it was run with a command-line argument. It then prints a message indicating whether an argument was received and what that argument was.

Example 2: A Practical Backup Script

Now for something more complex and useful. This script aims to back up a project directory.

Here's the script from the resource for easy reference:

#!/bin/bash
# Backs up a single project directory
# Ryan 2/3/2026

if [ $# != 1 ]
then
    echo Usage: A single argument which is the directory to backup
    exit
fi
if [ ! -d ~/projects/$1 ]
then
    echo 'The given directory does not seem to exist (possible typo?)'
    exit
fi
date=`date +%F`




# Do we already have a backup folder for todays date?
if [ -d ~/projectbackups/$1_$date ]
then
    echo 'This project has already been backed up today, overwrite?'
    read answer
    if [ $answer != 'y' ]
    then
        exit
    fi
else
    mkdir ~/projectbackups/$1_$date
fi
cp -R ~/projects/$1 ~/projectbackups/$1_$date
echo Backup of $1 completed

Let's break it down:

1. Top: Shebang is #!/bin/bash. Comments tell us it backs up a project directory and who wrote it.
2. Inputs:
   • $#: The number of command-line arguments.
   • $1: The first command-line argument (the project directory name).
   • read answer: Interactive input from the user.
   • Command substitution: date=\date +%F`captures the output of thedate` command into a variable.
3. Logic Flow:
   • First if: Checks if the number of arguments is not equal to 1. If so, it prints a usage message and exits. This is input validation.
   • Second if: Checks if the directory ~/projects/$1 does not exist (! -d). If it doesn't, it prints an error and exits. More input validation.
   • Third if-else: Checks if a backup for today already exists (-d ~/projectbackups/$1_$date).
     • If it exists, it prompts the user to overwrite (read answer) and has a nested if to exit if the answer isn't 'y'.
     • If it doesn't exist, the else block runs, creating the backup directory with mkdir.
4. Core Commands: The main actions are mkdir to create a directory and cp -R to recursively copy the project files into the new backup directory.
5. Output: It uses echo to provide usage instructions, error messages, prompts, and a final completion message.

Interpretation: This script automates the process of backing up a specific project directory. It's designed to be robust by first validating its input (correct number of arguments, existence of the source directory) and then handling the case where a backup for the current day already exists by asking the user for confirmation before proceeding.

The Main Event: Deconstructing a Log Analyzer

Now let's tackle a more advanced script. In the video below, the presenter builds a script to analyze log files. We will analyze the final version of that script, which uses variables, arrays, command substitution, nested loops, and conditionals.

Here is the final script we'll be interpreting:

#!/bin/bash

log_directory="/path/to/your/logs" #<-- Assumed path
error_patterns=("error" "fatal" "critical")
report_file="log_analysis_report.txt"
threshold=10

echo "Analyzing logs in $log_directory..." > $report_file
echo "Report generated on $(date)" >> $report_file

log_files=$(find "$log_directory" -name "*.log" -mtime -1)

for log_file in $log_files; do
    echo -e "\n--- Analyzing file: $log_file ---" >> $report_file
    for pattern in "${error_patterns[@]}"; do
        echo "Searching for '$pattern' issues..." >> $report_file
        
        grep "$pattern" "$log_file" >> $report_file
        
        error_count=$(grep -c "$pattern" "$log_file")
        echo "Found $error_count instances of '$pattern'." >> $report_file

        if [ "$error_count" -gt "$threshold" ]; then
            echo "WARNING: High number of '$pattern' issues in $log_file!"
            echo "ACTION REQUIRED: Too many '$pattern' issues ($error_count) in $log_file" >> $report_file
        fi
    done
done

echo -e "\n--- Analysis Complete ---" >> $report_file
echo "Log analysis complete. Report saved to $report_file"

1. Top: Shebang is #!/bin/bash. No comments, but the variable names are descriptive.
2. Inputs:
   • Hardcoded variables: log_directory, error_patterns (an array), report_file, threshold. These make the script configurable.
   • Command substitution: log_files=$(find ...) stores the output of the find command. This command finds all files ending in .log in the specified directory that were modified in the last day (-mtime -1).
3. Logic Flow:
   • Outer for loop: Iterates through each file path stored in the log_files variable.
   • Inner for loop: For each log file, it iterates through the error_patterns array ("error", "fatal", "critical").
   • if statement: Inside the inner loop, it checks if the error_count is greater than (-gt) the threshold.
4. Core Commands:
   • find: Locates the relevant log files.
   • grep "$pattern" "$log_file": Searches for the current error pattern within the current log file.
   • grep -c: Counts the number of lines matching the pattern.
5. Output:
   • All analysis output (echo, grep) is redirected (> for the first line, >> to append for all others) into the report_file.
   • A WARNING message is printed to the terminal and the report file if the error threshold is exceeded.
   • A final completion message is printed to the terminal.

Interpretation: This script is an automated log monitoring tool. It finds all log files modified in the last 24 hours, then systematically searches each file for a list of predefined error keywords. It generates a detailed report of its findings and, most importantly, provides an immediate alert to the console if the number of any specific error type in any single file exceeds a set threshold. This is a classic sysadmin/security task.

Your Turn to Interpret

Now it's your turn to apply the five-step method. Analyze the script below and describe its purpose and function.

#!/bin/bash




# A script to display system information

echo "--- System Information ---"
echo "Hostname: $(hostname)"
echo "Uptime: $(uptime -p)"
echo ""

echo "--- Memory Usage ---"
free -h | grep "Mem"
echo ""

echo "--- Disk Usage ---"
df -h / | tail -n 1
echo ""

echo "--- Network Information ---"
ip a | grep "inet " | grep -v "127.0.0.1"

echo "--------------------------"

Take a moment to analyze it before reading the explanation below.

Analysis:

1. Top: The shebang and a descriptive comment are present.
2. Inputs: There are no user-provided inputs. The script gets all its information from system commands via command substitution (e.g., $(hostname)).
3. Logic Flow: The script is purely sequential. It runs one command after another with no conditionals or loops.
4. Core Commands:
   • hostname: Gets the system's name.
   • uptime -p: Gets the system's uptime in a "pretty" format.
   • free -h: Shows memory usage in human-readable format.
   • df -h /: Shows disk usage for the root filesystem.
   • ip a: Shows network interface information.
   • It also uses grep and tail to filter the output of free, df, and ip to show only the most relevant lines.
5. Output: All output is printed to the terminal using echo to provide formatted headings for each section.

Interpretation: This is a simple system information-gathering script. It runs several standard Linux commands to collect key details about the system—hostname, uptime, memory, disk space, and IP address—and presents them in a clean, readable report on the command line. This kind of script is very useful for getting a quick health check of a server.

Conclusion

You now have a powerful and repeatable method for dissecting and understanding Bash scripts. This skill is a force multiplier; it allows you to learn from the work of others, leverage existing tools, and quickly understand the automated processes running on any Linux system you encounter.

Key Takeaways:

• Reading scripts is as important as writing them.
• A systematic approach (Top, Inputs, Logic, Commands, Output) can deconstruct any script.
• Understanding how variables, conditionals, loops, and command substitution work together is the key to interpretation.
• Descriptive variable names and comments are signs of a well-written, easy-to-understand script.

Next Lesson Preview:
This lesson concludes our module on Bash scripting. You've gone from basic commands to writing and interpreting complex automation scripts. In the next module, "System Internals: Services, Logs, and Scheduling," we'll take a deeper look at the operating system itself. You'll learn how to manage the core services that run in the background using systemctl, a crucial skill for any system administrator or penetration tester.