-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Cannot read from STDIN with read_to_string if reading before piping Rust program writes to STDOUT in another Rust program #141714
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
Comments
Does the sending part of the pipe ever close their end of it (e.g. by exiting)? If not, this is entirely expected behavior: Can you share the code for the sending part? Generally, |
Hmm. I agree with your observation. I had a similar idea last night while writing the bug report. To test that hypothesis, I tried adding a break. Same issue as reported. Tonight, I introduced a panic! on the sender to confirm that nothing gets picked up on the receiving end despite the pipe technically closing. Hello, the blank line, and the panic printout comes from the receiver. The JSON bit is actually printed from the receiving end. Nothing was sent to the other endpoint I was using in the test, but that might be a separate issue. The null hypothesis seems to be correct here. The pipe closure does allow the receiver to capture the input. I believe you are right. I did check the repository and confirmed that trait Depending on how you think it is best to proceed (and if you do not mind), this could be a great opportunity for me to open a PR and contribute. Thank you! |
Yeah, pointing this out in the docs seems like a good idea. I won't have the time to oversee a doc fix here, but if you just make a PR, a suitable reviewer will be assigned to that. :) |
@rustbot label A-docs |
Added a note to the two methods making clear that EOF is never reached/ expected to be reached if reading from an stdin pipe that does not get closed. |
Just to add more documentation to the record for future others that may fail to read the documentation, Once data is picked up from stdin, it looks like we never get back to 0 bytes. In this test, I broke reads into 512 bytes max using ...
It seems that the minimum resultant buffer is all zeroes. I am not sure if this is a side effect from the kernel or writing to stdout in Rust. This Go Reddit confirms our suspicions about reading and writing to std. Someone does recommend forcing a flush of buffers on writer side but my writer function already flushes after every write and the receiving end never triggers. At any rate, I could not figure out the reason for the returned 61 bytes upon completing the buffer reads from the code review alone. I will see if I return to this in the future to have a more complete account of events, but for now, I can just check if the first byte of a returned buffer is zero. That should be good enough for my purpose. Hopefully, this report helps others in the future. |
Using
std::io::read_to_string
,stdin().read_to_string
, orstdin().read_to_end()
blocks on nonexisting buffer and ignores incoming buffer. This happens if I pipe a program compiled with Rust to itself. For example,./target/debug/rumtk-v2-interface --port 55556 --local | ./target/debug/rumtk-v2-interface --daemon --outbound --port 55555 --local
. Reading using the buffer methods work well assuming I am able to piece together the buffer before converting to UTF-8 String. Flushing STDOUT from the piping program does not force the STDIN read to succeed.I tried this code. Only
read_some_stdin
works:I expected to see this happen: Have the stdout buffer pass to the stdin buffer of a Rust program piped to itself via the terminal. I expected to receive the buffer when reading or at least get an error I could handle/ignore if a read is empty.
Instead, this happened: Nothing happens even though program can read from stdin and write to stdout in isolated tests.
This is similar to forum? issue: [How to handle Stdin hanging when there is no input](https://users.rust-lang.org/t/how-to-handle-stdin-hanging-when-there-is-no-input/93512).
I am currently not sure why the issue happened after looking at the std library's STDIN source code, but I am not experienced in the codebase so it could be a me issue.
Thanks for your work on Rust and thank you for your help!
Meta
rustc --version --verbose
:Backtrace
The text was updated successfully, but these errors were encountered: