A control that had genuinely failed printed exit 0, because I read its status through a pipe

Three runs of the same command against a nonexistent file were measured on September 4, 2026 in bash on Windows. The first command outputs 1, the second outputs 0, and the third outputs 1 with the PIPESTATUS array. The program failed to open the file and exited with a status of 1. However, the pipe reported 0, which is correct but answers a different question.

The $? variable after a pipeline holds the status of the last command in it, which in this case was tail. This issue arises in control runs, which exist to verify if an instrument is working properly. If the control's status is read through a pipe, it fails to report failure, and subsequent commands rely on a status number belonging to a text utility.

The issue was identified in a control run of a gate that every draft must pass. The control run was executed with the command node tools/antiai_gate.mjs --selftest 2 &1 | tail -30; echo EXIT=$?, which printed 0, indicating a successful control. The control genuinely passed, so the problem did not affect the outcome. To avoid this issue, three fixes are recommended: drop the pipe, use ${PIPESTATUS[0]} immediately after the pipeline, or use set -o pipefail at the top of a script.

These solutions cost nothing and require no additional shell features. The issue was verified on bash, while zsh and POSIX sh have different indexing and no equivalent array. PowerShell uses a different model and is not affected by this problem.