Etienne
Etienne
@ChrisDryden are you talking about my PR #9620 or about some other PR? Did you really mean "both default SIGPIPE and SIGPIPE"? I don't understand what that means. Do you...
> Whoops meant to add the link to this pr with that comment #9184 > > I don't think this implementation covers: Default SIGPIPE and SIGPIPE ignored Thanks for the...
The CI errors are unrelated to my branch.
This is ready for review. I don't intend to work on this branch any more.
I've just seen https://github.com/uutils/coreutils/pull/9013#issuecomment-3446625332 which is also relevant for my PR. I'll check if [`Command::exec()`](https://doc.rust-lang.org/std/os/unix/process/trait.CommandExt.html#tymethod.exec) can be used instead of [`Command::status()`](https://doc.rust-lang.org/std/process/struct.Command.html#method.status).
The PR is ready for review.
Note that `Command::exec()` restores the default SIGPIPE signal handler (the rust startup code disables SIGPIPE signal handler). However in this particular case, I think having the default SIGPIPE signal handler...
I have started a draft PR restoring the default SIGPIPE signal handler in lib.rs: https://github.com/uutils/coreutils/pull/9620 . Can you please have a look?
@collinfunk I agree that the behavior or `SIGPIPE` should be inherited from the parent process, but it is not possible as long as the Rust startup code resets the `SIGPIPE`...
See also https://github.com/uutils/coreutils/pull/9184 which uses a static variable in order to read the SIGPIPE signal handler before the rust runtime resets it (I haven't tested whether this works).