JLine3 "steals" input from other program

[hyee]

It is possible that an application integrates Jline3 together with other program which uses its own read user input method. In such case, I found that Jline3 always "steals" the first character for each input line.

With below test code(in native console window), try input following lines:

• 11
• 11
• 11
• qq

And then the result likes below, the first char is eaten:

    Input: 1
    Input: 1
    Input: 1
    Input: q

Test code:

import org.jline.terminal.Terminal;
import org.jline.terminal.TerminalBuilder;
public class TestInput {
    public static void main(String[] args) throws Exception {
        Terminal terminal=TerminalBuilder.builder().system(true).exec(true).jansi(true).build();
        boolean exit=false;
        while (!exit) {
            System.out.write("Input: ".getBytes());
            while(true) {
                int c = System.in.read(); //Don't use JLine3 as the input reader
                if(c==10) break;
                if((char)c=='q') {
                    exit=true;
                    break;
                }
            }
        }
    }
}

[gnodet]

Yes, you're supposed to use the terminal.reader().

[gnodet]

The reason is that signals have to be processed as soon as possible, so that the input stream is read in advanced.
If you use terminal.reader(), it will work correctly. You can also set System.in() to actually return terminal.input() in case you can't change the code. That's what is done in the demo actually, so that all access to System.in() / out() / err() delegates to the current terminal, even if you have multiple incoming connections through ssh for example.

[hyee]

Thank you for your comment, actually the program is a C library, I think I can shutdown/run the reader before/after calling the relative C interface.

[hyee]

Maybe the terminal reader can be temoparily paused during the enter key is pressed and before new line request is raised

[gnodet]

Yeah, we could add a two methods to the terminal to pause/resume the input stream processing.
If you can't get around the problem, please reopen this or another issue.

[hyee]

That would be nice, thanks, previously I tested System.setIn to redirect the input of the C program, it didn't work so well.

[gnodet]

I've raised #140 and #141. I may be able to work on #141, but #140 is a bigger issue and I won't have the bandwidth in the short term.