Is there a way to avoid the "hit enter key" when reading lines from stdin using BufferedReader?

Question

The following is a simple but fully working Java program that demonstrates my issue:

package bufferedreader_test;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class BufferedReaderTest {

    public static void main(String[] args) {
        try {
            InputStreamReader isr = new InputStreamReader(System.in);
            BufferedReader br = new BufferedReader(isr);
            String line[] = new String[2];

            for (int i=0; i<2; i++) 
                line[i] = br.readLine();

            for (int j=0; j<line.length; j++)
                System.out.println(line[j]);
        } 
        catch (IOException e) {
            e.printStackTrace();
        }
    }
}

If you copy & paste 2 lines into the console, it will not print them immediately but rather wait for you to hit the Enter key (i.e. inject a newline into stdin).

For example:

Is there a way to "trick the system" into printing the result as soon as the 2nd line is read, without waiting for the Enter key (3rd line?) ?

`line[i] = br.readLine();` readLine is a *blocking* method, and will block all program flow until it receives an end-of-line token. — Hovercraft Full Of Eels, Oct 31 '22 at 17:30
A little further research turns up [this post](https://stackoverflow.com/q/1066318/18157) which confirms my suspicion that it is impossible to do in pure Java. — Jim Garrison, Oct 31 '22 at 17:50
Or try this [rabbit hole](https://www.google.com/search?q=java+non-blocking+stdin+console&client=firefox-b-1-d&ei=_ApgY7q0F4TA7gKYkKGoCw&ved=0ahUKEwi6oob9g4v7AhUEoFsKHRhICLUQ4dUDCBA&uact=5&oq=java+non-blocking+stdin+console) — Jim Garrison, Oct 31 '22 at 17:56
Thank you @JimGarrison I only ran into this issue because I tried to properly submit my solution at https://www.hackerrank.com/challenges/linkedin-practice-graph-theory-bfs/problem but it keeps resulting in runtime error *"~ no response on stdout ~"* despite running perfectly on my Eclipse setup. I wonder what that site is expecting. — WebViewer, Oct 31 '22 at 18:01
What is probably happening is that the input comes from a file, not a console, and there is no `\n` at the end of the second line. So the code sees EOF instead. — Jim Garrison, Oct 31 '22 at 18:04

score 2 · Accepted Answer · answered Oct 31 '22 at 17:35

2

You have two problems:

The console doesn't actually send anything to your program until you press ENTER. This allows you to edit the line before submitting it. There are OS-specific ways to get around this, but nothing you can do about it in pure/portable java.
br.readLine() doesn't know the line has ended until it receives the linefeed character that the console puts at the end of the text when you press ENTER. Without the enter key, how would it know that you were done typing? You could also type your OS-specific EOF character (probably ctrl-Z or ctrl-D) to terminate console input, but that's probably not what you want.

If you only want to solve this problem for manual copy and paste, then maybe you can just select the linefeed before you copy, by dragging all the way to line 3.

answered Oct 31 '22 at 17:35

Matt Timmermans

53,709
3
46
87

1

Selecting the linefeed before you copy, by dragging all the way to line 3 is a good workaround and it works! However, I cannot use this solution in the following automated test, which does not inject that extra line. As a result, it fails with *"~ no response on stdout ~"* runtime error: https://www.hackerrank.com/challenges/linkedin-practice-graph-theory-bfs/problem – WebViewer Oct 31 '22 at 17:49
hackerrank is not going to give you input without linefeeds. The code you posted is not appropriate for reading the input in that problem. – Matt Timmermans Oct 31 '22 at 19:21
What is appropriate (in Java) for reading the input in that problem, then? Would reading the input character-by-character (e.g. using `InputStreamReader(System.in).read ()`) do the trick? – WebViewer Oct 31 '22 at 19:39
I mean that the input to the problem has a variable number of lines, but you're trying to read exactly 2. You're probably running into trouble when the first line is `0`, because then there aren't any more. – Matt Timmermans Oct 31 '22 at 19:44
The variable number of lines is known right after reading the first line, so I took care of that (tested on my dev env. ) My only issue is that extra CRLF/EOF needed at the end, as you correctly pointed out. I tried Java's `Scanner.nextInt()` but I got the same results. I wonder what that site is expecting. Accepting your answer, as there seems to be no solution/workaround for the challenge I am facing. – WebViewer Nov 01 '22 at 13:26
You should post your actual input processing code. The problem is not what you think it is. – Matt Timmermans Nov 01 '22 at 22:58

Is there a way to avoid the "hit enter key" when reading lines from stdin using BufferedReader?

1 Answers1