From Discovery to Cleanup in One Session: Bash workflow notes
Incident response gets expensive when your shell session is a pile of one-off commands. The fastest engineers I work with do the opposite: they treat Bash as a scratchpad that produces reusable artifacts. The rule is simple: if you might need the result again in the next 15 minutes, write it to a file.
That keeps discovery, counting, triage, and cleanup in one session, instead of jumping between tabs and rerunning commands from memory. This workflow is based on Bash Ripple Practice: Incident Combo, and it’s the pattern I use when starting from a noisy incidents.log.
Start with durable discovery
First extraction should be explicit and reproducible:
grep 'WARN' incidents.log > warn.txt
Then count what you extracted:
cat warn.txt | wc -l
Yes, wc -l warn.txt is shorter. But the piped version makes the “input to output” flow obvious when sharing commands with teammates during triage.
The bigger point is sequencing: save first, count second. If you skip that, three failure modes show up quickly:
- Filtering without saving output, forcing rework.
- Counting the wrong file after extraction.
- Ignoring case/keyword conventions in the source log.
If your first move is grep ... | wc -l, you get a number but no artifact. Five minutes later someone asks for sample lines, and you rerun the command with a slightly different pattern. Now your evidence drifts.
Use naming that keeps your head clear
I use tiny report file names with one purpose each:
-
warn.txtfor warning lines -
error.txtfor error lines -
incident-focus.txtfor merged triage output
That sounds trivial, but under pressure, good file naming reduces mistakes more than clever shell tricks.
When logs are inconsistent, I switch from literal text to case-insensitive regex:
grep -Ei '\bwarn(ing)?\b' incidents.log > warn.txt
cat warn.txt | wc -l
-i handles WARN, Warn, and warning. \b boundaries reduce false positives.
A real troubleshooting moment: the “impossibly low count”
One Friday, I ran the obvious extraction:
grep 'WARN' incidents.log > warn.txt
cat warn.txt | wc -l
Observable symptom: count came back as 7, but monitoring had shown warning spikes all afternoon.
My first thought was missing data or log rotation. Wrong. The issue was my filter. The log used mixed tokens: Warn, WARNING, and WARN: in different services. I had asked for uppercase WARN only.
Fix:
grep -Ei '\bwarn(ing)?\b' incidents.log > warn.txt
cat warn.txt | wc -l
Count jumped from 7 to 83, and sample lines matched what operations were seeing. Same file, same session, no context switching—just a better extraction rule.
When counts don’t match reality, assume your pattern is wrong before assuming the system is wrong.
Add a second filtered report
After warning extraction is stable, create a separate error report instead of stuffing everything into one giant grep:
grep -Ei '\berror\b' incidents.log > error.txt
cat error.txt | wc -l
Then merge only if you need one combined artifact:
cat warn.txt error.txt > incident-focus.txt
cat incident-focus.txt | wc -l
Keeping separate files supports clearer decisions: “warnings up, errors flat” is more useful than one blended number.
Cleanup is part of the workflow
A session is complete only when it ends cleanly. If reports are temporary, remove them:
rm warn.txt error.txt incident-focus.txt
If they need to be retained, archive intentionally:
mkdir -p triage-archive/2026-04-11
mv warn.txt error.txt incident-focus.txt triage-archive/2026-04-11/
That keeps your next incident session clean, and prevents stale files from contaminating future counts.
For quick comparison: I still use PowerShell for object-heavy admin tasks, but for plain-text incident logs and fast file-based iteration, Bash with grep + redirection is usually the shortest path from discovery to cleanup.
Practice this workflow
If you want hands-on reps with this exact pattern:
- Bash training: https://windows-cli.arnost.org/en/bash
Primary source drill:
Similar drill:
What I've already written about
- Fast Navigation and Safer File Moves: Bash, zoxide, PowerShell, and Win-CLI
- Incident Triage Without Context Switching: Bash, zoxide, PowerShell, and Win-CLI
- A Repeatable Daily Shell Workflow: Bash, zoxide, PowerShell, and Win-CLI
Top comments (0)