Spurious "broken pipe" error

[infinity0]

$ cargo tree | head -n1
debcargo v1.3.0 (file:///$PWD)
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', src/libstd/io/stdio.rs:692:8
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Can be suppressed with 2>/dev/null but this also suppresses any other errors, and other UNIX tools don't need this.

[sfackler]

This is due to println! panicking on errors: https://github.com/rust-lang/rust/blob/f1ea23e2cc72cafad1dc25a06c09ec2de8e323eb/src/libstd/io/stdio.rs#L671.

C-based programs typically just get killed off with a SIGPIPE, but Rust ignores that signal.

[infinity0]

Do you mean the other way around? It seems rust isn't ignoring that signal here, whereas a simple 3 x hello-world program C program does this:

$ ./a.out | head -n1
Hello, world!
$ echo "${PIPESTATUS[@]}" 
0 0

Anyway, should I file this as a Rust bug then? For command-line "single-output" programs, it is surprising behaviour, and I guess that's why C defaults to ignoring it. But arguably it's useful to raise the error for long-running processes who's using the pipe for IPC.

[infinity0]

It's not all rust programs that are affected - a 3-line hello-world rust example also doesn't fail:

$ cat hello.rs 
fn main() { println!("hello"); println!("hello"); println!("hello"); }
$ rustc hello.rs; ./hello | head -n1
hello
$ echo "${PIPESTATUS[@]}" 
0 0

Some other rust programs also seem OK:

$ rustc --help | head -n1
Usage: rustc [OPTIONS] INPUT
$ target/debug/debcargo --help | head -n1
debcargo 1.3.0
$ cargo graph | head -n1
digraph dependencies {
$ cargo graph --help | head -n1
cargo-graph v0.3.1

cargo --help and cargo tree --help unfortunately print to stderr unlike the others so I can't really demonstrate it.

[sfackler]

Three "hello"s fit into the kernel-side buffer for the pipe, so hello finishes execution before the buffer closes. I'd guess the same is true for those other examples.

[infinity0]

Filed in rust, so closing.