-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fails tests in captive environments where stdin is closed #39
Comments
It's fine, we can just run the test as |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Our vendor tooling builds and tests cargo stuff in its own private space, where direct stdin is not available.
But a simple way to emulate the situations that causes this failure is redirecting
/dev/null
into stdin.A simple way to replicate this behaviour is:
the stdout test can also be made to fail by redirecting the test output via:
And the stderr test can also be made to fail by redirecting the test output via:
I understand that this is the problem domain atty is targeted at solving, so its a bit tricky, but I suspect the "right" thing to do here is have the tests in question exec a common binary internally, where, supposedly, you can control the availability and state of the various IO handles, that way, you're testing the logic, not testing whether or not the user is consuming the tests in an approved way.
The text was updated successfully, but these errors were encountered: