-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
tests
: Provide a way to run tests with PTY stdout
#5785
Comments
I was implementing something like this for the "nohup" tests. Its still pending as PR: #5858 I was testing multiple different external crates. Somehow I was falling back to implement it manually. I think if we decide to have it as part of the testing utilities then it makes sense to investigate again and a bit deeper. Especially because there are actually multiple crates that provides a similar functionality:
Was there a special reason why you suggest I did a very first rougth test with all of them and currently I think that "ptyprocess" (without the dash) is probably a good candidate as it seems to be easy to use and connects well with the |
update: After some testing, I have the feeling that all of the crates have some issue such that we can't directly use it. There is only on special thing to mention: |
the windows implementation for a pty in the rustlib is appartently not a new topic: I think the windows implementation is not urgend and thus we should wait for the rustlib being extened to support it with the std::Command. |
let me know what you think from proposal #5869 |
Thank you ! Anyway, from what I read and understood, that's exactly how I imagined it. |
Fixed by #5869 |
Some utils' behavior may change depending on the
stdout().is_terminal()
answer.This is the case for
ls
which adapts its default quoting style depending on STDOUT being a TTY or not.The issue is that from what I saw, the testing utilities do not provide any way to test these TTY behaviors.
Maybe we could adapt the utilities to offer such verifications.
A straighforward way to go would be to use the pty_process crate.
The text was updated successfully, but these errors were encountered: