install panics on broken pipe

[matthiaskrgr]

Noticed while mistyping grep cmd searching in cargo install --list output:

RUST_BACKTRACE=1 ./target/debug/cargo install --list  | grepp "foo"
zsh: command not found: grepp
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', libstd/io/stdio.rs:692:9
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:207
   3: std::panicking::default_hook
             at libstd/panicking.rs:223
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:402
   5: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:349
   6: std::io::stdio::_print
             at libstd/io/stdio.rs:692
             at libstd/io/stdio.rs:701
   7: cargo::ops::cargo_install::install_list
             at src/cargo/ops/cargo_install.rs:662
   8: cargo::commands::install::exec
             at src/bin/commands/install.rs:106
   9: cargo::cli::execute_subcommand
             at src/bin/cli.rs:83
  10: cargo::cli::main
             at src/bin/cli.rs:56
  11: cargo::main
             at src/bin/cargo.rs:40
  12: std::rt::lang_start::{{closure}}
             at /checkout/src/libstd/rt.rs:74
  13: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:306
  14: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  15: std::rt::lang_start_internal
             at libstd/panicking.rs:285
             at libstd/panic.rs:361
             at libstd/rt.rs:58
  16: std::rt::lang_start
             at /checkout/src/libstd/rt.rs:74
  17: main
  18: __libc_start_main
  19: _start

[lukaslueg]

Besides the error being a little verbose, I think it shows desirable and correct behavior. As cargo's stdout is not writeable, all attempts to write to it return an error. The standard mechanism is to assume that the program can't continue anyway in a useful way and should therefore just stop. We could cushion this by manually writing to stdout and checking for errors every single time; we'd have to come up with a sensible alternative to a panic for every situation, though. This would almost certainly look like a little less verbose version of a panic, so nothing is gained.

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[joshtriplett]

This is still an issue, and I just encountered it recently. wasmtime checks if cargo-fuzz is installed by doing cargo install --list | grep -q cargo-fuzz. Sometimes, but not always, doing so will result in this panic:

$ cargo install --list | grep -q cargo-fuzz
$ cargo install --list | grep -q cargo-fuzz
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', src/libstd/io/stdio.rs:792:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

[sqwishy]

I get this too when piping cargo search into a thing. It didn't used to. I'm not sure what changed.

I updated with rustup and still see it.

nightly-x86_64-unknown-linux-gnu updated - rustc 1.42.0-nightly (859764425 2020-01-07) (from rustc 1.42.0-nightly (da3629b05 2019-12-29))

[ehuss]

I was taking a look at this and trying to understand how most tools typically behave. I'm thinking perhaps it makes sense to have different behavior for different commands. I'd propose: things like cargo search or cargo install --list can ignore errors printing to stdout. Regular builds (like cargo build) should error out if stdout or stderr is closed. That seems to match the behavior of other tools I've looked at. A lot of C-based tools ignore errors from printf. But the build tools I tested all exit with an error if stdout is closed. @joshtriplett WDYT?

[joshtriplett]

On Sun, Jan 26, 2020 at 03:35:16PM -0800, Eric Huss wrote: I was taking a look at this and trying to understand how most tools typically behave. I'm thinking perhaps it makes sense to have different behavior for different commands. I'd propose: things like `cargo search` or `cargo install --list` can ignore errors printing to stdout. Regular builds (like `cargo build`) should error out if stdout or stderr is closed. That seems to match the behavior of other tools I've looked at. A lot of C-based tools ignore errors from `printf`. But the build tools I tested all exit with an error if stdout is closed. @joshtriplett WDYT?

Sounds reasonable to me. The question to ask is "is the output of this something that might get piped to a pager, filter, or similar, and should this tool die if not all of its output is seen or captured". So, tools that should exit quietly on EPIPE: - cargo install --list - cargo locate-project - cargo metadata - cargo owner --list - cargo pkgid - cargo read-manifest - cargo run - cargo search - cargo version