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

Jan Burse wrote:
> Joshua Cranmer schrieb:
> > Perhaps it could just be that Java was not designed for the use cases
> > you're trying to shove it into.
>
> My words. The thing is neglected since 1995.
>
> Why 1995?
>
> http://ibiblio.org/java/slides/hope/03.html

Aside from the fact that the library has changed significantly even in the last couple of releases, therefore your statement that it hasn't is wrong, your words are that it is "neglected", which is not what Joshua or others are saying. You've thoroughly failed to offer any evidence in support of an accusation of neglect, other than your own whining about a portable system's lack of support for a very non-portable feature, much less proof.

In the course of your bratty little baby act, you've apparently ignored thevarious pieces of good advice on how to work around your roadblock in favor of more pouting.

My sympathy for you was real, but you've eroded it completely away. Stop whining. Get over yourself, Jan. Your petulance does not constitute a business need.

Or you could hold your breath in protest until you turn blue. Why don't youdo that?

--
Lew

On 3/12/2012 7:33 PM, Jan Burse wrote:
> Joshua Cranmer schrieb:
>> Perhaps it could just be that Java was not designed for the use cases
>> you're trying to shove it into.
>
> My words. The thing is neglected since 1995.

Lots of thing has changed over the years both in language, library
and JVM.

They may not have made the changes you want, but you don't always get
what you want.

Arne

Lew schrieb:
> thoroughly failed to offer any evidence in support of an accusation of neglect,

Very simple, since the thing is still broken in 2012.

> Or you could hold your breath in protest until you turn blue.

Your stubbornness amuses me. Makes multi-tasking
less boring. One window open with comp.lang.java.programmer
makes my day. The more simpler and evident the issue,
the more wackyer the voices. Priceless...

Bye

On 3/12/2012 7:56 PM, Jan Burse wrote:
> Lew schrieb:
>> thoroughly failed to offer any evidence in support of an accusation of
>> neglect,
>
> Very simple, since the thing is still broken in 2012.

Can you point to where in Java docs that it says that
it should behave as you think it should behave?

Arne

Arne Vajhøj schrieb:
> Lots of thing has changed over the years both in language, library
> and JVM.
>
> They may not have made the changes you want, but you don't always get
> what you want.

One more guy who gets a masturbation organsm
by saying: Its your fault.

Doesn't help at all. As far as I can see the
thread no substantial help has arrived so far.

Neither some patch has been recommended, nor
something else. Calling it an issue about
more fine control over the terminal is ridiculus.
I have checked the possibility already. I don't
see that it is an ioctrl issue.

Windows console has a flag PROCESS_INPUT, but
it looks like that switching off this flag
totally disables the Ctrl-C, it will then
neither invoke the signal nor return an EOF.
So there is no control possible, either the
full package of signal and EOF is delivered
or nothing.

But MS spec says also how to detect it on
the receiving side. So probably the some
workaround would be a class:

FileInputStreamFix

Which would override the read() method
of the FileInputStream. This I guess would
be an easy patch I could apply, since I
have access to the location in the application
where the input stream is retrieved, and
can give the application another object if
necessary.


I have already checked a couple of libs:
- JLine: http://jline.sourceforge.net/
- Java Curses: http://sourceforge.net/projects/javacurses/

But it looks to me that they do much more
than simply patching windows. They are often
multi platform and not so small.

So if somebody has already worked on
such a class I would be interested.

Bye

P.S.: People who can't stand working on solutions,
please simply refrain from the thread.

Arne Vajhøj schrieb:
>
> Can you point to where in Java docs that it says that
> it should behave as you think it should behave?

I didn't say that. I can also work with
a patch. See other post.

Jan Burse wrote:
> One more guy who gets a masturbation organsm
> by saying: Its your fault.

You are an ass. In this case you are getting valid feedback and this is howyou characterize it?

> Doesn't help at all. As far as I can see the
> thread no substantial help has arrived so far.

You apparently only call "help" that which your preconceived notions limn. You've gotten plenty of help, but you didn't like what you heard, notwithstanding that it was true, accurate and useful. You've occupied 75% of your posts in this thread with whining and cursing, and now abusing those who've attempted to help you. Your lack of civility does not constitute error on our part. You are an ass.

> P.S.: People who can't stand working on solutions,
> please simply refrain from the thread.

How about people who reject advice that they ask for, and get snarky and abusive about it, refrain from posting? That would be you, Jan.

--
Lew

On 3/12/2012 8:05 PM, Jan Burse wrote:
> Arne Vajhøj schrieb:
>> Lots of thing has changed over the years both in language, library
>> and JVM.
>>
>> They may not have made the changes you want, but you don't always get
>> what you want.
>
> One more guy who gets a masturbation organsm
> by saying: Its your fault.
>
> Doesn't help at all. As far as I can see the
> thread no substantial help has arrived so far.

Actually you have been given the best
possible help: we have told you that Java
is probably not the right language for
your app.

Arne

On 3/12/2012 8:05 PM, Jan Burse wrote:
> Arne Vajhøj schrieb:
>>
>> Can you point to where in Java docs that it says that
>> it should behave as you think it should behave?
>
> I didn't say that. I can also work with
> a patch. See other post.

If what you want is not in the docs, then it
is not broken as you claim.

You just disagree with the design.

Arne

On 3/12/2012 7:05 PM, Jan Burse wrote:
> Doesn't help at all. As far as I can see the
> thread no substantial help has arrived so far.

My recommendations:
1. Find some way to not need this.
2. Write a JNI library that implements what you want to do.
3. Use another programming language.

If you're still not happy, then I suspect you're probably in the wrong
profession.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Martin Gregorie wrote:
....
> - When I found that I needed single keystroke input for another project
> that must be capable of operating in a console/headless environment
> and that System.in won't release keystrokes to the program until
> newline has been typed, I wrote that Java program to read characters
> from a Socket and a small C program to send keystrokes to it via the
> socket. This also works well and does what I wanted with the other
> advantage that I *know* it will work in both headless and console
> environments since there are no Swing or AWT classes or packages
> involved.

I've found that general strategy useful for dealing with other
specialized activities that are not directly supported in Java. For
example, I needed some intense matrix manipulation that was not
supported well in any library I found, but was trivial in Matlab. The
combination of a Java program with a very small Matlab program did
everything I needed.

Patricia

On 11/03/12 20:57, Jan Burse wrote:
> CtrlCRunner ctrl = new CtrlCRunner();
> ctrl.installCtrlC(
> new Runnable() {
> public void run() {
> /* do nothing ! */
> }
> }
> );

What class is this? Is it specified somewhere?

Cheers!

--
ss at comp dot lancs dot ac dot uk

Arne Vajhøj schrieb:
> If what you want is not in the docs, then it
> is not broken as you claim.

Its simply broken because of the following
chain of reasoning.

- InputStream/OutputStream are supposed
to be blocking IO in contrast to NIO.

- When a shutdown sequence is initiated
no InputStream/OutputStream is killed
they remain blocking in case they were
already blocking.

so that the shutdown hooks can gracefully
terminate their service. For example
a goodbye sequence with a web server, etc..

- SIGINT when available, by default
initiates a shutdown sequence.

- The Windows behaviour for CONIN$ violates
the above, since during SIGINT the
CONIN$ becomes non-blocking in that
it returns EOF.

So this is what is broken here. It contaminates
any sensible use of shutdown hooks as described
here in the case of Windows:
http://docs.oracle.com/javase/1.4.2/...lang.Thread%29

Best Regards

On 03/12/2012 08:35 PM, Jan Burse wrote:
> Silvio Bierman schrieb:
>> Given the fact that tons of developers have consistently chosen
>> differently since 1995, it is very likely that your view on this is
>> flawed.
>
> I guess your are subject to the same brainwash like
> the subjects in "The Emperor's New Clothes". I even
> don't feel pitty for you.

I suppose I am not the original out-of-the-box thinking mind you are.

Some empathy on your side would have been nice.

Steven Simpson schrieb:
> What class is this? Is it specified somewhere?

Its a custom made wrapper for Signal & SignalHandler.
In version 1 of the above class I used the package
sun.misc.*. In version 2 of the above class I
used reflection i.e. Proxy class etc.. It will
noop when sun.misc.Signal is not present.

See for example:

http://stackoverflow.com/questions/2...andler-in-java

It is not portable, since sun.misc.* is not official
part of the JDK. But testing showed that the reflection
stuff works fine for the cases when sun.misc.* is
present.

The reflection thing is also useful when the code by
chance lands in an applet. Some verifier murne the use
of sun.misc.* inside an applet, even if during the
execution of the applet the package is not called.

There is some post on the web where Oracle/Sun claims
they never said they WILL remove sun.misc.*, they only
said they MIGHT remove sun.misc.*.

Best Regards