Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF?

On 13/03/12 13:11, Jan Burse wrote:


I was going to suggest using Runtime.addShutdownHook(Thread) as a
portable alternative. You don't find out which signal was raised, but
it gives your program a chance to shut down gracefully instead of abruptly.

import java.io.*;

public class TestInput {
     public static void main(String[] args) throws Exception {
         Runtime.getRuntime().addShutdownHook(new Thread() {
                 public void run() {
                     try {
                         Thread.sleep(10 * 1000);
                     } catch (InterruptedException ex) {
                     }
                 }
             });

         FileInputStream fs = new FileInputStream(FileDescriptor.in);
         byte[] buf = new byte[256];
         for (;;) {
             System.out.print("test: ");
             int len = fs.read(buf);
             String str = new String(buf,0,Math.max(0,len));
             System.out.println("len = "+len+", buf = "+str+", buf[0]="+buf[0]);
             if ("exit".equals(str.trim())) break;
         }
     }
}

Unfortunately, you still get the same read()==-1 on Windows, while the
read call doesn't return on Linux. Of course, this loop doesn't
terminate on EOF, and while the shutdown hook is still running, you can
continue to type on both Windows and Linux, and have the results printed.

However, this could be a way to distinguish the 'fake' EOF from a real
one. Having received -1, read again. A real one will produce -1 again,
but the fake one will block or yield more input. For a real EOF, the
behaviour seems the same on Windows and Linux, so stop when you get two
'-1's. Can't speak for Mac, or anything else, of course.

Is a read() call's behaviour well defined after a previous call returned
-1? I couldn't tell from a quick scan of the docs.

--
ss at comp dot lancs dot ac dot uk