Ok, well my first suspect turned out to be right: I can see the data is buffered in the JDK-provided streams. This means one of two things: we were not able to unwrap the buffering, or chose not to for various reasons.
Some versions of JDK (I think 7+, unfortunately) now drive the subprocess streams by themselves, constantly draining them. This makes true interactive subprocesses impossible, and along with them many uses of Ruby. On UNIX platforms we have worked around this by implementing our own process logic that uses posix_spawn and achieves good compatibility. However, on Windows, process management is more complicated, and we have not yet had the resources to mimic the logic in MRI.
I do not know why this would have changed from 9.1.13 to 9.1.14, however. I'll review logs for changes to process and IO logic and see if something jumps out.
Provide at least:
Windows 10 64bit
jruby 126.96.36.199 (2.3.3) 2017-11-08 2176f24 Java HotSpot(TM) Client VM 25.144-b01 on 1.8.0_144-b01 +jit [mswin32-x86]
In jruby 9.1.13, this command outputs "a"
In jruby 9.1.14, no return
On Linux, it returns "a"
The text was updated successfully, but these errors were encountered: