Scala REPL ignores redirected standard input on Windows

[scabug]

On Unix-like systems (including Mac OS X), the Scala REPL ("scala" command) can be run from the shell by redirecting input in from a file, as in:

scala < Test.scala

The contents of Test.scala are processed by the REPL as if they were typed interactively. Once the contents of the file have been processed, the REPL exits.

This mode of using the REPL is used by my Scala Worksheet plugin for Sublime Text 3 (https://bitbucket.org/inkytonik/scalaworksheet). The output of the REPL is captured and used to associated input code with the output that it produces.

Unfortunately, this mode of execution of the REPL does not work on Windows 7, even though the Windows CMD shell supports input redirection. Anecdotally from plugin users it doesn't work on other versions of Windows too.

I have tested 2.11.0-M4 but the problem occurs in 2.10.2, 2.9.2 and the latest nightly as well.

The observed behaviour on Windows 7 is that the REPL starts up as normal, but it behaves as if nothing was redirected in. I.e., it just goes to the prompt and waits for interactive input.

I'm not sure whether there is any specification of what the REPL should do in this circumstance, but it would be particularly useful for my plugin if it behaved on Windows the way it does on other systems. As we stand, the plugin is not usable on Windows so it's a blocker for me.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-7703?orig=1
Reporter: Tony Sloane (asloane)
Affected Versions: 2.11.0-M4

[scabug]

@harrah said:
You might try -Djline.terminal=none. It is possible that jline doesn't (or can't) check that standard input is a proper terminal.

[scabug]

Tony Sloane (asloane) said:
Thanks for the suggestion. Unfortunately, it doesn't seem to make any difference on Windows 7.

BTW, on Mac OS X adding that option makes things worse: the REPL still executes the expressions from the file, but doesn't echo them and goes into an infinite prompt-printing loop at the end of the file.

[scabug]

@harrah said:
Perhaps it is not a jline issue then. Things you might try: see if sbt 0.13 accepts redirection on windows and try running the raw jline example from the jline2 repository: https://github.com/jline/jline2/blob/master/src/test/java/jline/example/Example.java.

[scabug]

Tony Sloane (asloane) said:
Now checked. sbt 0.13 and the jline2 example behave as scala does (ignoring redirected input on Windows). So it appears to be a jline2 issue.

I will join the jline2 list and ask if this is expected behaviour.

[scabug]

@harrah said:
Ok, closing. If something needs to be done in Scala or sbt, please reopen/open.

[scabug]

Tony Sloane (asloane) said:
Some discussion on the jline-users list revealed that opening the terminal reader as follows:

ConsoleReader console = new ConsoleReader(System.in, System.out, new TerminalSupport(true) {});

seems to be a workaround for this input redirection problem when using JLine 2.11.

At least, with this change the jline example program now properly accepts stdin redirection on Windows 7.

How do you feel about trying this change in the scala REPL and in sbt?

[scabug]

@harrah said:
I don't think this is a proper fix or a general workaround. new TerminalSupport(true) {} looks like a hack around something depending on the specifics of the input stream and it forces the terminal into supported mode when that might not be the case. I'd like to see it properly fixed upstream.

[scabug]

Tony Sloane (asloane) said:
Yeah, fair enough. I'll officially report a JLine bug and see if I get more traction. The only person to respond on the JLine mailing list was Paul Phillips...

[scabug]

Tony Sloane (asloane) said:
JLine issue is here: jline/jline2#103

[scabug]

Tony Sloane (asloane) said:
Just for the record, it appears that a work-around for this problem is to set the jline.WindowsTerminal.directConsole system property to false. This works for JLIne examples, but doesn't work for the Scala REPL due to a bug in Scala's version of JLine (#7061).

[scabug]

@retronym said (edited on Oct 20, 2013 5:14:50 PM UTC):
#7061 is fixed in 2.11 (by virtue of using the released version of JLine). So for this bug we need to figure out if we have a non-interactive stdin on Windows and set the same property. Mark, any ideas how to do that?

[scabug]

@harrah said:
Tony references how to detect non-interactive stdin in the JLine issue. Now that we are on the standard JLine, my preference is to push these bugs upstream to avoid sinking a lot of time into JLine issues. The problem is that pull requests aren't getting merged into JLine lately.

[scabug]

@retronym said:
I'm going to close this one Won't Fix then. Hopefully the workaround (explicitly passing -Djline.WindowsTerminal.directConsole) will suffice.

[scabug]

Tony Sloane (asloane) said:
The work-around is fine for my use case, thanks.