You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've run into an issue when using the Scala REPL with standard input redirection on Windows 7. This is a blocker for my Sublime Text 3 Scala Worksheet plugin which relies on input redirection to run the REPL.
After some experimentation it seems that the issue is due to the way that JLine behaves. In more detail and removing the Scala complication, I compiled and ran the example from here:
Some code reading revealed a partial work-around for this problem. WindowsTerminal.java says:
By default, the {@link #wrapInIfNeeded(java.io.InputStream)} method will attempt
to test to see if the specified {@link InputStream} is {@link System#in} or a wrapper
around {@link FileDescriptor#in}, and if so, will bypass the character reading to
directly invoke the readc() method in the JNI library. This is so the class
can read special keys (like arrow keys) which are otherwise inaccessible via
the {@link System#in} stream. Using JNI reading can be bypassed by setting
the jline.WindowsTerminal.directConsole system property
to false.
It appears that using JNI reading causes the stdin redirection not to work. Setting that property to false makes it work again. For my use case this is a reasonable workaround, since I am running the JLine-using program in a non-interactive setting where things like arrow keys can't be used.
I've run into an issue when using the Scala REPL with standard input redirection on Windows 7. This is a blocker for my Sublime Text 3 Scala Worksheet plugin which relies on input redirection to run the REPL.
After some experimentation it seems that the issue is due to the way that JLine behaves. In more detail and removing the Scala complication, I compiled and ran the example from here:
https://github.com/jline/jline2/blob/master/src/test/java/jline/example/Example.java
as
where input contains
On Windows 7 the prompt appears but the program apparently sees none of the input from the file, so it just sits there waiting for interactive input.
On Mac OS X the input is passed through to the program as expected and the program exits when the end of file is reached.
Opening the terminal using
makes it work, but this doesn't seem like a desirable general approach.
The text was updated successfully, but these errors were encountered: