exit on broken pipe

[rirze]

Using a pipe to restrict the output of skim -f <somestring> results in an error:

thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', src/libstd/io/stdio.rs:805:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The error is innocuous, yet should probably be addressed in a future commit. Ideally, skim should terminate once it encounters a Broken Pipe error internally. ripgrep has gone through this same feature progression, as documented by these links:

BurntSushi/ripgrep#200
https://github.com/BurntSushi/ripgrep/pull/586/files

In that discussion, there is a hacky fix to terminate the program once it encounters a SIGPIPE error. This fix is what I have included in this PR.

Like @BurntSushi laments, this error should be handled naturally within the program. I'm not too comfortable with Rust so I wasn't able to understand how he handles in ripgrep, but in case anyone wants to understand it, the commit that makes this feature possible is at https://github.com/BurntSushi/ripgrep/pull/1017/files#diff-639fbc4ef05b315af92b4d836c31b023

I've tested this hotfix on my local machine and it seems to terminate as expected. Speed wise, I am not seeing any difference.

[BurntSushi]

ripgrep today handles this by inspecting I/O errors. If it's a broken pipe, then ripgrep quits gracefully. For example: https://github.com/BurntSushi/ripgrep/blob/50d2047ae2c0ce2edb5189ae3071538e21b15822/crates/core/main.rs#L95-L98

This approach is also a fine one to take, and mirrors how a CLI program written in C would behave by default. (SIGPIPE is suppressed by Rust's runtime, so this is kind of a Rust thing to deal with.)

[lotabout]

@rirze Gonna close this and choose the inspecting approach. Thanks!