Directly forward execution output to stdout #370
Conversation
Issue #336 is caused by the Process being started using `.!!` which: ``` Starts the process represented by this builder, blocks until it exits, and returns the output as a String. Standard error is sent to the console. If the exit code is non-zero, an exception is thrown. ``` This uses `.!<` instead, which: ``` Starts the process represented by this builder, blocks until it exits, and returns the exit code. Standard output and error are sent to the console. The newly started process reads from standard input of the current process. ``` Note: This should also allow reading from stdin now (but I have not tested this yet).
|
Apparently this is used in some way during testing. Am investigating. |
|
This is still suboptimal, but it does allow for input and output, and at least streams the outputs on a line-by-line basis (So, a |
|
|
||
| override def out(s: => String): Unit = { | ||
| C.config.output().emitln(s) | ||
| System.out.flush() |
There was a problem hiding this comment.
Do we need to flush each time?
There was a problem hiding this comment.
We can probably drop this; it is left over from trying to get the ordering right when printing not-full-lines.
emitln should flush anyway.
|
It's great that you made progress here. But I would have hoped to just have a thin wrapper that acts exactly like programming against the host native interface. |
Co-authored-by: Jonathan Immanuel Brachthäuser <jonathan@b-studios.de>
|
This was mostly a product of me reading into the process API docs anyway. If I understand that correctly, then we'd need to change how tests are run (because they currently check the output in |
Fixes #336 (since I was looking into the Process API r.n. anyway).
Issue #336 is caused by the Process being started using
.!!which:We now use a custom
ProcessLoggerand also connect stdin.This makes this mostly work, apart from potential race conditions between input and output. (Note:
.!<would work well in that regard but breaks the tests.)