vp aborts with SIGABRT when stdout is piped to a reader that exits early (| head)

[Mina-Sayed]

Repro (v0.3.1 linux-x64-gnu, also v0.3.0)

$ vp --version | head -n 1
vp v0.3.1
$ echo ${PIPESTATUS[0]}
134

Same with any command that prints, e.g. vp env list-remote --lts | head.

What happens

systemd-coredump records SIGABRT. Strings extracted from the core show the panic message:

thread 'main' panicked at library/std/src/io/stdio.rs:1168:9:
failed printing to stdout: Broken pipe (os error 32)

Root cause is the classic Rust EPIPE footgun: the runtime ignores SIGPIPE, println! panics on the resulting EPIPE error, and the binary is built with panic=abort, so a truncated pipe becomes SIGABRT plus a coredump.

Related

#223 fixed the same panic in a tokio-runtime-worker thread, but the main-thread print path is still affected in 0.3.1 — every vp subcommand that writes to stdout can hit it.

Expected

Exit quietly like standard Unix tools: restore SIG_DFL for SIGPIPE at startup (what ripgrep/bat/fd do), or swallow ErrorKind::BrokenPipe on stdout writes.

Impact beyond the crash itself

Each occurrence litters a systemd coredump, and crash-notification tooling that re-runs vp to investigate (e.g. an agent running vp --version | head) turns one abort into a self-amplifying crash loop — I watched one vp env list-remote abort cascade into several more vp --version aborts this way.