Stop your subshells from swallowing your exit codes

Technical Briefing | 7/16/2026

We have all been there. You write a nice, clean pipeline, piping the output of a command into a while loop to parse some data. It looks perfect in testing. But then you realize that if the core command in your pipe fails, your script keeps chugging along like nothing happened. Bash essentially ignores the exit status of everything except the very last command in your pipe, and that’s how silent production disasters start.

Why your exit status is lying to you

By default, the exit status of a pipeline is the status of the last command. If you run something like cmd1 | cmd2, and cmd1 crashes, you never see it because cmd2 succeeded. Most folks try to work around this with manual status checks, which are tedious and usually wrong. The right approach is to toggle a shell option that tells Bash to pay attention to the entire pipeline’s health.

set -o pipefail
command_that_might_fail | grep "error" | process_data

• pipefail changes the exit status to the last command that returned a non-zero value
• It applies to the entire script unless you explicitly turn it off
• Your pipeline will now correctly trigger an exit if an early stage bombs out

Once you turn this on, make sure you check the PIPESTATUS array if you need to know exactly which segment of the pipe caused the trouble. It’s a standard variable that stores the exit codes of every command in the last executed pipeline. Relying on it is much safer than guessing why your production automation silently drifted into a corrupted state.

Try adding set -o pipefail to your template files. It takes five seconds to implement, and it will save you hours of debugging why your data processing script reported success while outputting garbage.