Path: csiph.com!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Jan Burse Newsgroups: comp.lang.java.programmer Subject: Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF? Date: Tue, 13 Mar 2012 18:44:07 +0100 Organization: albasani.net Lines: 74 Message-ID: References: <3jc439-dc4.ln1@s.simpson148.btinternet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net kQ+bzVWNSZnMco0bgHNUVpAQCVjqMrHb0kEUYqT5K64isl8sYfAk1Fx96pwvr/DkqkVE9MdHArm1IR+U3KvdQLl23qvrD00DJMSISKU5padwqF7qxU3tAJcEuhkWLoSX NNTP-Posting-Date: Tue, 13 Mar 2012 17:44:07 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="4Ji0lzTZEYm4IU1cZRWESFVWuxreJLZJ2uIyVSYr5RS0qgWiVbKOTX+I1Mfs1FUpvEl+8VELw7hq7DRnbFlc1TQdeCUZBCdLeVl3QFwz0NRFZm3lk9OmY3kYKfyetaD3"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Firefox/10.0.2 SeaMonkey/2.7.2 In-Reply-To: <3jc439-dc4.ln1@s.simpson148.btinternet.com> Cancel-Lock: sha1:L/NlTprZDtFxVKVCrnEfPdFPWHE= Xref: csiph.com comp.lang.java.programmer:12978 Steven Simpson schrieb: > I was going to suggest using Runtime.addShutdownHook(Thread) as a portable In the final application the SIGINT should enter a monitor, and the end-user can then choose among other things whether he would like to abort the application or not. But the effect is of course also seen with ordinary shut down hooks. When one overrides the SIGINT with the help of Signal/SignalHandler the shutdown sequence is not anymore called. But the handler is free to call System.exit() which will initiate the shut down sequence. > Unfortunately, you still get the same read()==-1 on Windows, while > the read call doesn't return on Linux. Yes, on Linux, it is as it should be. The read call is blocking. > 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 Actually the standard input stream is special. It can return -1 but will not close. And then after returning -1 it will return normal user input. This works for Linux, Mac and Windows. So one can enter: abc def Where depends on the platform (^D on Mac and Linux, ^Z + Enter on Windows). When doing Buffered str = readLine(). One gets: str = "abc" str = null str = "def" str = null The above is perfectly fine and intended. And one can write applications that use recursive stream input. The only issue on Windows is now that SIGINT injects a EOF. I don't think that in my Monitor case a continued reading might detect the SIGINT EOF. Since the SIGINT will not perform a System.exit(). I guess that eventually in the non-Monitor case after a System.exit() or so, the continued reading might show something, IOException or so. Not sure. But getting two EOF in general might be just the user interaction, and not a SIGINT EOF. Getting two EOF is actually a legal user interaction in my application. For example on can recursively open a REPL, and then exit form it: ?- break. [1] ?- break. [2] ?- [1] ?- ?- Bye