Implement tee -p #3656
Implement tee -p #3656
Conversation
|
Could you please add a test ? |
|
ping? |
|
I've been looking into it; it's a bit more complicated to test, and even more complicated to match GNU tee's behaviour. I do have a fairly complete implementation with tests now, include the extended --output-error option, but I've been fighting with clap to permit an optional value with --output-error. So for example, this command fails: because clap wants a value for --output-error. I have fixed the termination/error behaviour to match GNU tee more closely however; this is the last failing test in my set. |
|
I should've rebased before pushing; will fix. |
eds-collabora
force-pushed
the
eds/tee_p
branch
2 times, most recently
from
f6f0451
to
04002a5
Compare
|
I believe I've fixed the majority of the test failures reported last time:
|
|
Three failures in the last batch:
I'm hoping I've fixed the first two. |
|
@sylvestre I don't understand how the remaining two errors relate to this code:
I'm not sure how to address these. |
|
They aren't your fault. For grcov, see mozilla/grcov#849 |
|
See that GNU tee.sh is still failing. Do you know why ? |
I've had a quick look, and should be able to fix. There are still quite a few things wrong:
I'm investigating. |
|
I'm not sure all these commits belong in here, and perhaps parts are a little questionable. But I did make the GNU tests for tee pass with these commits. Their main value is just to show the gap between the first commit and a fully passing GNU test set.
|
|
Indeed: Well done! |
|
I believe the remaining test fails are not related to these patches. I'm happy to modify this PR, whatever makes sense from your perspective. I can drop the extra fixes, or move them into their own PRs, as desired (or leave them here, obviously). |
|
sorry but it seems that the gnu test regressed: |
I'm not sure what happened here. If I run this test locally with what is supposedly the same code I get a test pass for tee. The failure log is empty in the logs from CI (just a nonzero exit code). Any ideas what the variation could be from? |
This has the following behaviours. On Unix: - The default is to exit on pipe errors, and warn on other errors. - "--output-error=warn" means to warn on all errors - "--output-error", "--output-error=warn-nopipe" and "-p" all mean that pipe errors are suppressed, all other errors warn. - "--output-error=exit" means to warn and exit on all errors. - "--output-error=exit-nopipe" means to suppress pipe errors, and to warn and exit on all other errors. On non-Unix platforms, all pipe behaviours are ignored, so the default is effectively "--output-error=warn" and "warn-nopipe" is identical. The only meaningful option is "--output-error=exit" which is identical to "--output-error=exit-nopipe" on these platforms. Note that warnings give a non-zero exit code, but do not halt writing to non-erroring targets.
When the monitored process exits, the GNU version of timeout will preserve its exit status, including the signal state. This is a partial fix for timeout to enable the tee tests to pass. It removes the default Rust trap for SIGPIPE, and kill itself with the same signal as its child exited with to preserve the signal state.
This is part of fixing the tee tests. 'yes' is used by the GNU test suite to identify what the SIGPIPE exit code is on the target platform. By trapping SIGPIPE, it creates a requirement that other utilities also trap SIGPIPE (and exit 0 after SIGPIPE). This is sometimes at odds with their desired behaviour.
tee is supposed to exit when there is nothing left to write to. For finite inputs, it can be hard to determine whether this functions correctly, but for tee of infinite streams, it is very important to exit when there is nothing more to write to.
|
back |
This amounts to enabling pipe errors when -p is not specified, but only on unixish platforms.
This addresses issue #3648