uutils
lib.rs: restore default SIGPIPE signal handler
Rust's start-up code sets the SIGPIPE signal handler to ignored. However the vast majority of the utilities should use the default signal handler for SIGPIPE rather than ignore SIGPIPE. (in reality those utilities should inherit the signal handler from their parent process, but this is not possible with current rust start-up code).
Instead of restoring the default signaler handler in individual utilities, do it in lib.rs and add some logic in the utilities which can't use the default SIGPIPE signal handler (cat, env, seq, split, tail, tee, tr, tty).
GNU testsuite comparison:
GNU test failed: tests/sort/sort-compress-proc. tests/sort/sort-compress-proc is passing on 'main'. Maybe you have to rebase?
Skip an intermittent issue tests/tail/overlay-headers (fails in this run but passes in the 'main' branch)
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
GNU testsuite comparison:
GNU test failed: tests/sort/sort-compress-proc. tests/sort/sort-compress-proc is passing on 'main'. Maybe you have to rebase?
GNU testsuite comparison:
GNU test failed: tests/sort/sort-compress-proc. tests/sort/sort-compress-proc is passing on 'main'. Maybe you have to rebase?
Skip an intermittent issue tests/timeout/timeout (fails in this run but passes in the 'main' branch)
GNU testsuite comparison:
GNU test failed: tests/sort/sort-compress-proc. tests/sort/sort-compress-proc is passing on 'main'. Maybe you have to rebase?
Skipping an intermittent issue tests/tail/overlay-headers (passes in this run but fails in the 'main' branch)
There's a PR here that does some advanced stuff to get both Default SIGPIPE and SIGPIPE ignored to match GNU behavior but it does it in a totally different way.
@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 mean "both default signal SIGPIPE handler and custom SIGPIPE handler"?
Whoops meant to add the link to this pr with that comment https://github.com/uutils/coreutils/pull/9184
I don't think this implementation covers: Default SIGPIPE and SIGPIPE ignored
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 link. This is very interesting. I hope it can work that way.