Bash Lab: Turn Repeated Analysis Into a Small Script

A script is useful when you need to perform the same approved analysis more than once.

This lab uses a harmless teacher-provided log file. You will write a small Bash script that summarizes evidence. It does not change accounts, permissions, services, or network settings.

The problem

The supplied file login-events.txt contains fictional records such as:

09:01 SUCCESS user=alex
09:02 FAILED user=guest
09:04 FAILED user=guest
09:06 SUCCESS user=maria

Your script should answer three questions:

• How many successful events exist?
• How many failed events exist?
• Which fictional usernames appear in failed events?

Practice the evidence commands first

Use the bounded terminal below before writing the script. The log is fictional and the command set is deliberately limited to evidence extraction.

Garden State Cyber grep simulation
The login records are fictional and local to this lesson. No real account logs are exposed.
Type 'help' for supported evidence commands.

$ cat login-events.txt
09:01 SUCCESS user=alex
09:02 FAILED user=guest
09:04 FAILED user=guest
09:06 SUCCESS user=maria
09:08 FAILED user=sam
09:10 SUCCESS user=alex

$ wc -l login-events.txt
6 login-events.txt

$ grep 'FAILED' login-events.txt
09:02 FAILED user=guest
09:04 FAILED user=guest
09:08 FAILED user=sam

$ grep 'FAILED' login-events.txt | wc -l
3

$ grep 'SUCCESS' login-events.txt | wc -l
3

The purpose is to prove each command against known input before automating it. If a manual command produces the wrong evidence, a script will only repeat the wrong answer faster.

Start manually

Before scripting, prove each command works by itself.

Examples:

grep "SUCCESS" login-events.txt | wc -l
grep "FAILED" login-events.txt | wc -l
grep "FAILED" login-events.txt | grep -o 'user=[^ ]*' | sort | uniq

The exact pattern must match the supplied lab format.

If a manual command is wrong, putting it in a script only automates the wrong answer.

Build the script

A classroom-safe structure might look like:

#!/usr/bin/env bash

LOG="login-events.txt"

success_count=$(grep "SUCCESS" "$LOG" | wc -l)
failed_count=$(grep "FAILED" "$LOG" | wc -l)

printf "Success events: %s\n" "$success_count"
printf "Failed events: %s\n" "$failed_count"
printf "Users in failed events:\n"
grep "FAILED" "$LOG" | grep -o 'user=[^ ]*' | sort | uniq

Do not copy this blindly. Explain every line and adapt it only to the approved file.

Variables make assumptions visible

The variable:

LOG="login-events.txt"

centralizes the input file.

If the script is supposed to analyze a different approved file later, the input can change without rewriting every command.

Quote paths

Using:

"$LOG"

helps the shell treat the expanded value as one argument when paths contain spaces or other special characters.

The deeper lesson is that shell syntax affects how text is interpreted.

Add a safety check

Before analysis, verify the file exists:

if [[ ! -f "$LOG" ]]; then
  echo "Expected lab log not found."
  exit 1
fi

A script should fail clearly rather than produce misleading output from the wrong environment.

Test against known evidence

The teacher provides a small test log with known counts.

Run your script and compare:

• expected successes
• actual successes
• expected failures
• actual failures
• expected usernames
• actual usernames

If the output differs, debug the smallest stage first.

Add one extension

Choose one approved extension:

• count ERROR records
• show the first failed event
• show the last failed event
• write the summary to the approved evidence directory

Do not add commands that modify users, delete logs, stop services, or probe networks.

Explain the script as evidence

Create an annotation table:

A script you cannot explain is not a tool you should trust.

Evidence for Lesson 3

Submit:

• working classroom script
• known-input test results
• annotation table
• one approved extension
• one paragraph describing a failure condition your script detects

Finish with:

Automation helps an analyst only when the script's assumptions are ________.

The goal of shell scripting here is not complexity. It is making a repeatable evidence workflow explicit.