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

[Arne Vajhøj]

Do you see some Ctrl-D or Ctrl-Z in my code? Except
as explanatory in a prompt?


Do you see some Ctrl-C in my code?

No but you ask users to enter it and complain
about its behavior.

Here is a reminder for you: The posed problem is as follows

IF sigint is supported THEN how sould
FileInputStream(FileDescriptor.in) behave?

I don't care about those platforms where there is no sigint.
The problem is then automatically resolved. The IF THEN
is trivially true.

If a feature is not generally available it does not really
belong in Java (well - a few exceptions has been mad over
the years, but ...).

And even though it is in the true spirit of Java to have
well defined behavior, then you should expect it if the docs
does not say so.

Could they do something in this area. I would guess so. But
given how few that seems to consider it a problem, then it
may very likely end up far down the priority list.

Arne

 

[Jan Burse]

No but you ask users to enter it and complain
about its behavior.

No, I only gave an example. The example does also
go wrong on the Windows platform when you use (I
tested it):

cygwin

And for example issue a kill from another process.
Its deeply rooted in the behaviour of CON respectively
CONIN$. And it is even documented by MS.

Bye

 

[Robert Klemme]

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.

Unfortunately most conspiracy theories are wrong - there is usually not
the subject or group with worst of intentions who managed to trick
everybody else into believing some BS. Reality is often so much more
complicated - or much simpler, in any case: very different from what
CT's suggest.

Kind regards

robert

 

[Arne Vajhøj]

No, I only gave an example.

So how does one see the problem without using any CTRL
keys?

And for example issue a kill from another process.

Also OS specific.

Arne

 

[Robert Klemme]

No, I only gave an example. The example does also
go wrong on the Windows platform when you use (I
tested it):

cygwin

And for example issue a kill from another process.
Its deeply rooted in the behaviour of CON respectively
CONIN$. And it is even documented by MS.

What do you expect then? A signal handler is concurrent by design. If
the OS implementors chose to also automatically EOF the console the two
cannot know from each other without introducing synchronization overhead
just for this single case. I doubt for any serious JVM implementor
would trade off in this direction.

Plus, since there is concurrency involved there is not much guarantees
cross platform anyway. I also agree to Arne's position that it is
unwise to commit on EOF and rollback otherwise: the more robust code is
always to commit only when explicitly advised and rollback in all other
cases. Because only with explicit advice to commit you know the code
behaved as intended. But if a program crashes or dies otherwise (OOM
for example) you cannot know whether all intended changes were applied.

So yes, the example is quite artificial (you also called it "naive"
IIRC). But what follows from bad code?

Cheers

robert

 

[Joshua Cranmer]

Personal or not. Face it, the Java library hasn't
much evolved since 1995. I am not talking about the
Java language, the Java language itself did a
tremendous development, we have Generics and super
cool good performant 64-bit JITs.

Asides from an improved graphics libraries, improved basic data
structures, new support for time library, improved support for
concurrency, features to allow the use of dynamic scripting languages
that more or less seamlessly integrate with Java, improved
self-reflective capabilities, and other things, no it hasn't changed at all.

Oh wait, you're complaining because it doesn't have a good support for
console? Maybe this is because true console support just generally
doesn't matter to a language primarily developed in the GUI age. And
also the fact that consoles are handled quite differently on Windows
(where knowledge of a terminal is comparatively rare) and Unix (where a
lot of people prefer terminal administration to GUI administration).

Perhaps it could just be that Java was not designed for the use cases
you're trying to shove it into.

 

[Jan Burse]

each other without introducing synchronization overhead just for this
single case. I doubt for any serious JVM implementor would trade off in
this direction.

Thats a good point. It could be that the following hack
is not thread safe:

http://www.mail-archive.com/[email protected]/msg01846.html

But may something could be done with for a readBytes() returning
len = 0 versus len = -1.

The upper layers BufferedReader etc.. anyway introduce their own
locks, and they can do the re-read when len = 0.

But this is also most often blured, there are different implementations
among the different JDKs, some are not able to do the re-read and
other ares.

My only requirement would be that allternating Threads can use
BufferedReader readLine and the len = 0 does not confuse these
readLines, i.e. add additional empty lines.

I think the later requirement is easily archiveable.

Bye

 

[Jan Burse]

readLines, i.e. add additional empty lines.

Or worse add additional EOFs.

 

[Jan Burse]

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

Bye

 

[Lew]

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?

 

[Arne Vajhøj]

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

 

[Jan Burse]

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

 

[Arne Vajhøj]

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

 

[Jan Burse]

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.

 

[Jan Burse]

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.

 

[Lew]

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.

 

[Arne Vajhøj]

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

 

[Arne Vajhøj]

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

 

[Martin Gregorie]

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

Not necessarily a class, but I know two ways of getting single-keystroke
input into Java:

- use a KeyAdapter to get the key value from each key press event.
This certainly works well inside a Swing application: I've used it
to accept keystrokes for a terminal emulator.

I initially thought this would not work in a headless environment
and/or a console environment because its java.awt.event package:
which is why I implemented my second suggestion. Now I'm not so
sure that's right but I haven't tried using it in a headless/console
environment. If you try it, I'll be most interested to hear if it
works in a headless environment.

- 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.

 

[Joshua Cranmer]

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.