Just for grins, I tried to reproduce on Windows NT4 workstation SP6a, with
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
I tried witih input from console, redirect from text file, and pipe from text file. All worked. However, I see something I didn't expect for input from the console, which may be evidence of a problem in the Java library that might lead to system-dependent results.
Windows NT 4, as have its ancestors back to at least CP/M, treats a line beginning with control-Z as an end of file indication. And as expected, when reading from System.in, typing
<ENTER><control-Z><ENTER>
causes System.in.read() to return -1. However, if you issue another System.in.read(), it blocks instead of returning -1 immediately (which is what it returns when reading from a file or pipe). So the Java library seems to be asking the OS for another octet even though it is already recognized the end of file. If you now type <letter><Enter>, read() returns the code for the letter you typed, instead of -1.
This suggests to me that the Java reading from the console after it has already indicated EOF. Perhaps the results of this is different for Win2000 than for NT4 or Win98.
In case it is of interest, here is my
test program. Can anyone see a flaw in my obsevation?
<pre>
import java.io.IOException;
class SystemInReadTest {
public static void main(
String[] args) throws IOException {
while (System.in.read() != -1)
{ }
System.out.println("Got EOF, reading again gives...");
System.out.println(System.in.read());
}
}
</pre>
[This message has been edited by John Dale (edited May 06, 2001).]