All means are fair except solving the problem

An industry veteran added a misuse warning to his code; downstream scripts broke because they parsed stdout for a success string. No one fixed the misuse.

What Matters

• Scripts detected failure by matching the literal string “yay, done” as the final line of stdout, not by checking exit codes.
• Warnings printed from destructors or atexit handlers appeared after “yay, done”, breaking the contract silently.
• Proposed workarounds: re-print “yay, done” from a destructor, suppress warnings by default, or route warnings to a separate file.
• Someone had already implemented the re-print-in-destructor hack independently, for an earlier identical problem.
• Exit-code hygiene and stdout parsing conflict: exit(0) can lie about completion; the string check was added precisely to catch early-exit bugs.
• [HN: @linkregister] POSIX convention is stderr for non-output messages; 2>&1 conflation in scripts is the root structural failure here.
• [HN: @yosefk] The “yay, done” string guards against exit(0) debug commits that make the program appear to succeed before running to completion.

Original | Discuss on HN