Better interaction with pagers (Broken pipe)

[omasanori]

Since the result of verification can be hundreds of lines or more, I use the command with a pager, exit in the middle, and then a "Broken pipe (os error 32)" error occurs. It is not a critical problem but it would be great if we can get rid of the error.
I am using cargo-crev 0.15.1, installed with cargo on Ubuntu 18.04 (amd64) on WSL.

backtrace

$ RUST_BACKTRACE=1 cargo crev crate verify | less
Error: Broken pipe (os error 32)
stack backtrace:
   0: failure::backtrace::internal::InternalBacktrace::new
   1: failure::backtrace::Backtrace::new
   2: cargo_crev::deps::print_term::print_dep
   3:  as core::iter::traits::iterator::Iterator>::next
   4:  as alloc::vec::SpecExtend>::from_iter
   5: cargo_crev::deps::verify_deps
   6: cargo_crev::run_command
   7: cargo_crev::main
   8: std::rt::lang_start::{{closure}}
   9: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:48
      std::panicking::try::do_call
             at src/libstd/panicking.rs:287
  10: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:78
  11: std::panicking::try
             at src/libstd/panicking.rs:265
      std::panic::catch_unwind
             at src/libstd/panic.rs:396
      std::rt::lang_start_internal
             at src/libstd/rt.rs:47
  12: main
  13: __libc_start_main
  14: _start

[dpc]

Are you aware what's the proper behavior? Detect an ignore broken pipe error on write?

[omasanori]

Yes, I guess that catching an error and exit the process is fine. I had searched web and found corresponding Rust issue: rust-lang/rust#46016.

[BurntSushi]

See also:

• Should Rust still ignore SIGPIPE by default?
• ripgrep doesn't stop when its pipe is closed

The simplest possible fix is to stop ignoring the SIGPIPE signal, which will cause your process to terminate immediately once a SIGPIPE is received. The other approach is what @dpc mentioned.

[chrysn]

Ignore would IMHO be suitable behavior if there were any valuable processing done. It may or may not be suitable for a cargo crev repo fetch all, but a cargo crev crate verify should just use the default UNIX behavior and terminate.