Nobody announces small features. You ship them, they're in there, and the people who find them either notice or they don't. I want to start documenting these because some of them are the kind of thing that makes a tool actually worth using day-to-day instead of being something you visit once and close.
Six updates across six tools this week. None of them are headline features. All of them are fixes for specific annoyances that came up in my own usage, which is the only real source I trust for "does this actually help."
1. Bash Boilerplate Generator — Trap & Cleanup Handler
There's a now a toggle for trap handling. When on, the generated template includes:
cleanup() {
# Remove temp files, release locks, undo partial changes
rm -f "$TMPFILE"
}
trap cleanup EXIT INT TERM
Why this matters: trap cleanup EXIT means the cleanup() function runs no matter how the script exits. Normal completion. Ctrl+C. An uncaught error. A kill signal. The cleanup function runs. Every time.
Without this pattern, scripts that create temp files leave them behind when they're interrupted. Scripts that acquire lock files leave them locked. Scripts that make partial changes — creating a directory, writing part of a config — leave the system in an inconsistent state because the cleanup code at the end of the script never ran.
The trap-on-exit pattern is not optional for anything running unattended. It's the thing that separates "runs fine when nothing goes wrong" from "also recovers gracefully when something does." I've seen this pattern left out of boilerplate generators enough times that I wanted to make it explicit and easy to include.
The generated stub includes a TMPFILE=$(mktemp) line as a concrete example of something that needs cleanup. Replace it with whatever state your script actually manages.
→ bashsnippets.xyz/tools/bash-boilerplate-generator
2. Bash Exit Code Lookup — Export as case Statement
After looking up an exit code, there's a button that generates a ready-to-paste case $? in ... esac block with the explanation inline as a comment.
Before this, the lookup gave you the meaning of the exit code and you had to write the case handler yourself. That's not hard — the case syntax is simple — but it's friction. You looked up what 126 means ("command found but not executable — check permissions"), now you have to translate that into:
case $? in
0) echo "Success" ;;
1) echo "General error" ;;
126) echo "Command found but not executable — check file permissions" ;; # ← the one you just looked up
127) echo "Command not found — check PATH or typo" ;;
*) echo "Unknown exit code: $?" ;;
esac
The export button generates that block for you, with the specific code you looked up highlighted in the right place and the explanation preserved as a comment. Paste it directly into your script. No rewriting the syntax from scratch.
The case template includes the four most common exit codes (0, 1, 126, 127) plus the wildcard catch-all. Delete the ones you don't need.
→ bashsnippets.xyz/tools/bash-exit-code-lookup
3. Cron Job Builder — Next 5 Run Times
This is the one I wanted for myself.
Enter any cron expression — say, 0 3 * * 1-5 — and it now immediately shows the next five times it will fire:
Next run times for: 0 3 * * 1-5
1. Mon Jun 09 2026 03:00:00
2. Tue Jun 10 2026 03:00:00
3. Wed Jun 11 2026 03:00:00
4. Thu Jun 12 2026 03:00:00
5. Fri Jun 13 2026 03:00:00
The problem this solves: cron expressions are easy to get subtly wrong. 0 3 * * * fires at 3am. But 3am what — your server's local time or UTC? And is your server set to UTC? And does */6 mean every 6 hours starting at midnight, or starting at the first minute it's defined? And does 0 9 * * 1 fire on Monday or Sunday, depending on which cron implementation counts week starts?
Without something that shows you the actual fire times, you add the job, wait until the next day, and find out whether your assumptions were right or wrong. If they were wrong, you change it and wait another day. It can take three or four days to confirm a cron expression fires when you want it to, purely because of iteration time.
Showing the next five run times eliminates that cycle entirely. You know immediately whether your expression does what you think it does. Change it, verify it, add it to your crontab — all in under a minute.
→ bashsnippets.xyz/tools/cron-job-builder
4. Chmod Calculator — World-Writable Warning and Live Symbolic Mirror
Two updates here bundled together because they're related.
World-writable warning:
Enabling any world-write bit (the w in the "others" column) now shows a warning banner:
⚠️ World-writable permissions mean any user on the system can modify this file or directory. This is rarely correct. Verify this is intentional.
This is the chmod 777 trap. I've seen chmod 777 applied as a "quick fix" for permission errors more times than I can count. It works immediately, which is why people do it. The fact that it means "literally every user and process on this system can write to this file" gets lost in the urgency of making the error go away.
The warning doesn't prevent you from setting world-writable permissions. It just makes sure you've seen the words "any user on the system can modify this" before you click confirm. If you intended that, the warning is just noise. If you didn't, it might save you.
Live symbolic ↔ octal mirror:
Every permission you configure now shows both forms simultaneously:
Octal: chmod 755
Symbolic: chmod u=rwx,go=rx
Both update in real time as you toggle permissions. This is useful for two reasons: you see the octal code for when you need to type it quickly in a terminal, and you see the symbolic form for when you need to express the same permission in a script where the explicit form is easier to read and maintain. Neither is "more correct" — they're the same thing expressed two ways, and having both removes the mental step of converting between them.
→ bashsnippets.xyz/tools/chmod-permissions-builder
5. PATH Debugger — Duplicate Entry Detector
Duplicate entries in $PATH accumulate over years. Every time a tool's installer adds itself to your PATH, every time you add an entry to .bashrc, every time a package manager prepends its bin directory to your environment — the list grows. On machines that have been around for a while, or on developer laptops where tools get installed and removed and reinstalled, you can end up with /usr/local/bin listed four times.
Duplicate entries don't usually cause obvious breakage. The correct binary still runs. It just runs with slightly more PATH resolution overhead on every command, and the duplicate entries make it harder to reason about which version of a tool will actually be picked when you have multiple installed. If /usr/local/bin appears before /usr/bin, the local install wins. When it appears four times, you've lost track of the actual resolution order.
The debugger now flags repeated entries and generates a one-liner to deduplicate and export a clean PATH:
# Generated dedup command:
export PATH=$(echo "$PATH" | tr ':' '\n' | awk '!seen[$0]++' | tr '\n' ':' | sed 's/:$//')
That pipeline: converts PATH from colon-separated to newline-separated, uses awk to keep only the first occurrence of each entry, converts back to colon-separated, and strips the trailing colon. The resulting PATH has the same resolution order as the original but with all duplicates removed.
Add that line to the bottom of your .bashrc and your PATH will deduplicate itself on every new shell session.
→ bashsnippets.xyz/tools/path-debugger
6. ShellCheck Error Decoder — Inline Script Scanner
ShellCheck is the best static analysis tool for bash scripts. If you're writing bash and you're not running your scripts through ShellCheck, you're missing real bugs. I'll say that plainly.
The problem is that ShellCheck error codes (SC2086, SC2046, SC1091, etc.) are meaningful if you know what they mean and opaque if you don't. When ShellCheck tells you SC2086: Double quote to prevent globbing and word splitting, that makes sense. When it just gives you SC2086 in isolation, you have to look it up.
The inline script scanner adds a paste box where you put your bash script directly. The tool maps recognized SC error codes to the lines in your script where they appear — not in the abstract documentation, but in your specific code. You see the line, the SC code, and the explanation together.
Important caveat I want to be direct about: this is not a replacement for running actual ShellCheck. The real ShellCheck tool parses bash properly, handles edge cases, and catches issues that a pattern-matcher won't. If you're writing scripts that matter, install ShellCheck and run it directly:
# Install
apt install shellcheck # Debian/Ubuntu
brew install shellcheck # macOS
# Run
shellcheck yourscript.sh
What the decoder in BashSnippets tools is useful for: understanding what a specific SC code means in the context of your own code rather than in a reference page. It's a learning tool and a quick lookup, not a substitute for the real thing.
→ bashsnippets.xyz/tools/shellcheck-error-decoder
All tools are free, no login, no account required. The full tools index is at:
Top comments (0)