make, ping and nc: exit codes that quietly don't check what you'd assume

What it is

Three tools an agent commonly shells out to each have one exit code whose meaning is easy to assume incorrectly.

make: "GNU make exits with a status of zero if all makefiles were successfully parsed and no targets that were built failed. A status of one will be returned if the -q flag was used and make determines that a target needs to be rebuilt. A status of two will be returned if any errors were encountered." Outside of -q, exit 1 does not occur for ordinary builds — a normal failed recipe produces exit 2; the Error 1 in make's message is the recipe's code, not make's.

ping: "If ping does not receive any reply packets at all it will exit with code 1 ... On other error it exits with code 2. Otherwise it exits with code 0." Exit 1 is ping working correctly and reporting "no answer" — a down host, a firewall drop, or a wrong address that still resolves. Exit 2 is reserved for ping itself misbehaving (bad arguments, unresolvable name, permission problems).

nc/ncat: implementations vary and many (including OpenBSD's netcat) do not document a formal exit-status table. Nmap's Ncat does: "The exit code reflects whether a connection was made and completed successfully. 0 means there was no error. 1 means there was a network error of some kind ... 2 is reserved for all other errors, like an invalid option or a nonexistent file." Treat any other nc variant's code as unverified unless you check its own documentation.

openssl s_client: its -verify option documents a real gotcha: "Unless the -verify_return_error option is given, the verify operation continues after errors ... As a side effect the connection will never fail due to a server certificate verify failure." Without that flag, a completed TLS session exits 0 even with an invalid, expired or self-signed certificate.

Why it matters

Each case turns a naive "0 good, else bad" check into a wrong conclusion: make's -q mode inverts the usual sense of 1, ping's exit 1 is a legitimate network observation rather than a broken invocation, and openssl s_client's default exit 0 can mean "connected to an attacker with a bad certificate," not "connection verified."

How to apply

• With make -q, treat exit 1 as the expected "needs rebuild" signal and reserve real error handling for exit 2.
• Use ping's 1-vs-2 split to separate "host unreachable" (1, worth alerting on the target) from "ping itself failed" (2, worth checking your own arguments).
• Prefer nc -z with your specific implementation's documented codes, or check its output text; don't assume semantics transfer between OpenBSD nc, GNU netcat and Ncat.
• Always add -verify_return_error and -verify_hostname <name> to openssl s_client calls used for automated certificate checks; without the first, exit 0 proves nothing about the certificate, and without the second a valid certificate issued for a different name still exits 0.

Pitfalls

• Scripting make -q; [ $? -eq 0 ] || echo "build broken" — a -q exit of 1 means the opposite of broken.
• Trusting a bare openssl s_client ... ; echo $? as a certificate-validation check.