Stop Googling "what is exit code 127" There's a better way to handle it

Exit code 127 means "command not found." I know that now. But the first dozen times I saw it, I Googled it. Every time. Because exit codes are one of those things that are fundamental to bash scripting but never feel intuitive until you've been burned by them enough.

Here's a quick table of the ones that show up constantly:

Code	Meaning
0	Success
1	General error
2	Misuse of shell built-in
126	Command found but not executable
127	Command not found
130	Script killed with Ctrl-C
137	Process killed with SIGKILL (kill -9)
139	Segmentation fault
143	Process killed with SIGTERM

The rule for codes above 128: subtract 128 to get the signal number. 137 = 128 + 9 (SIGKILL). 143 = 128 + 15 (SIGTERM). Once you know that pattern, a lot of the high-numbered codes make sense.

---

But looking up the code is only half the problem

The other half is writing the error handler. And this is where most scripts fall short. They check $? after a command, but the handler is usually something like:

if [ $? -ne 0 ]; then
  echo "something went wrong"
  exit 1
fi

Which tells you almost nothing when you're looking at logs at 2am.

I built a tool that generates a proper handler for any code you give it.

---

The Exit Code Lookup tool

You go to https://bashsnippets.xyz/tools/bash-exit-code-lookup.html, type in a code — or click one of the common ones — and you get:

• What the code means
• The most likely causes (this is the part that actually saves time)
• A copy-paste error handler in your choice of format: if/else block, case statement, or inline || fallback

The if/else output names the code explicitly, logs what failed, and exits with the same code so the calling process knows something went wrong. The case statement version is better if you're handling multiple possible outcomes. The inline || is what you want when you're doing something quick and you just need a fast bail-out.

One thing I added that I actually use myself: the quick-click buttons for the codes you see constantly. You don't have to type 127 — just click it, get the handler, copy it.

---

Common situation this actually helps with

You're writing a script that calls a binary. You want to handle the case where the binary isn't installed (127), the case where the binary exists but fails on the input (1), and the case where someone Ctrl-C'd it (130). Those three cases need different responses — log and exit, retry with different args, clean up and exit gracefully — and the case statement the tool generates is structured for exactly that.

---

The thing I keep adding to all my scripts now

trap 'echo "Script failed at line $LINENO with exit code $?" >&2' ERR

Put that near the top of any script that matters. When it fails — and things fail — you know exactly where and with what code. Pair it with the exit code lookup when you're not sure what the code means, and you cut debugging time significantly.

---

Try it: https://bashsnippets.xyz/tools/bash-exit-code-lookup.html

No signup. All 256 codes (0-255) are in there. The handlers are copy-ready and production-quality, not the half-baked one-liners you find on random Stack Overflow answers.