-
Notifications
You must be signed in to change notification settings - Fork 18
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to flush each time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
ProcessLogger
and 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.)