[plicease]

For the initial implemetnation.

[plicease]

dup2 returns a file descriptor on success, including 0 for stdin, so using // is correct here. However, the exec-failure reporting pipe appears to rely on Perl's $^F close-on-exec behavior. I'd add a test specifically verifying that an executable which fails at exec reports a structured client.spawn_failed error and leaves no child behind.

A second area worth testing is close() after the subprocess has already died. The implementation is careful about reaping and escalation, but subprocess lifecycle edge cases are notoriously difficult to get right.

[plicease]

Addressed in ee06b15.

Exec failure / close-on-exec

• Every pipe end is now marked FD_CLOEXEC explicitly rather than relying on $^F, and the child copies its three ends above fd 2 (F_DUPFD) before dup2-ing them onto 0–2, so one can't overwrite another if the caller has closed a standard handle. (For the record, the previous code turned out to be safe in practice because of the order the pipes are created in; this removes the dependency on that ordering.)
• New tests in t/openapi_humbug_transport_command.t: an executable that passes -f/-x but fails at exec (#!/nonexistent/interpreter) gives transport / client.spawn_failed with no child left behind (waitpid(-1, WNOHANG) == -1), both directly and through OpenAPI::Humbug->new; construction returns while the child is still running (spawns are under a 5s alarm, so a leaked status pipe fails instead of hanging — verified by temporarily breaking it); and spawning works with STDIN, STDIN+STDOUT, and all three standard handles closed.

close() after the child died

• Killed with SIGKILL: close doesn't throw, returns false, reaps, and doesn't wait out the grace period.
• Exited 0 on its own: close doesn't throw and returns true.
• Already reaped by someone else: close doesn't throw.
• Destroyed after the child died: no error; validate after death is a transport error (client.eof/client.broken_pipe), never a result.