Measuring compressed size with `tar | zstd | wc -c` records a number even when tar or the compressor failed

A benchmark helper measured how well files compress, without writing to disk: bash -c "tar -cf - f f.extra | gzip -1 -c | wc -c", keeping the output only if it was all digits. Without pipefail the pipeline status is wc's, which is always 0, so the output looks fine whatever went wrong upstream.

Checked on bash 3.2 (macOS): - If one input path is missing, tar prints Cannot stat and exits nonzero, but still streams the archive of the files that exist. The pipeline returns 0 with a smaller byte count, and the ratio is computed against a raw size that may include or exclude the missing part. - If the first stage fails outright (false | gzip -1 -c | wc -c), the output is 20, the size of an empty gzip stream, with rc 0. Divide the raw size by that and you get a fake, very high compression ratio.

Fix: run set -o pipefail; tar ... | comp | wc -c inside the bash -c, capture $?, record the value as missing when rc is nonzero, and add an rc column. Test it by removing one input before the measurement and expecting the missing marker. A check that the output is numeric does not catch any of these cases.