Ctrl-C firing twice

[Brad Wood]

Whenever I press Ctrl-C while realLine() is running, I'm seeing it fire the UserInterruptException twice most of the time.  I'm on Windows inside of cmd.  This seems to happen whether or not I have the signalHandler in my builder.

If I add a sleep of 200 ms before dealing with it, I don't see the behavior.  In this instance, I'm just outputting the message to the user

Use the "exit" command to leave this shell.

and immediately entering another readLine() call.

I think what is happening is that my key down and key up are possibly both firing the handler, and since I'm immediately re-entering the readLine(), the second firing is getting captured as well.  That would seem to explain why sleeping for 200 ms before running readLine() again doesn't fire the handler a second time.  

Is this a bug?
Do I actually need to set the signal handler since it seems to work regardless?  

I also see that Ctrl-D throws an org.jline.reader.EndOfFileException.  Cool.  Is there any way you can help me understand what the possible signals are, what keystrokes create them, and what Java exceptions to expect?  I realize you said that JLine support the typical terminal signals, but that really doesn't help me know what keystrokes will generate what specific Java exceptions.  

From my Googling, it seems that the actual keystrokes may be interpreted different based on the termain I'm using so I understand if it's not the same across all OS's etc but a basic guide would be great here.

For instance, I'm seeing the standard *nix terminal is supposed to allow:

Ctrl+C - SIGINT

Ctrl+\ - SIGQUIT

Ctrl+Z - SIGTSTP

Thanks!

~Brad

Developer Advocate

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

[Guillaume Nodet]

Could you check if the behavior is specific to windows maybe ?

You may be right about keydown / keyup, but that's specific on windows, as other OSes are plain character based.

The signal is raised here:

  https://github.com/jline/jline3/blob/master/terminal/src/main/java/org/jline/terminal/impl/AbstractWindowsTerminal.java#L417

--
You received this message because you are subscribed to the Google Groups "jline-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jline-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brad Wood]

I'll try to do some testing.  Right now this is all local on my Windows dev machine.

Do I actually need to set the signal handler since it seems to work regardless?  Are certain handlers set up by default?

Is there any way you can help me understand what the possible signals are, what keystrokes create them, and what Java exceptions to expect?

Thanks!

~Brad

Developer Advocate

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

[Guillaume Nodet]

The handlers are handled on the terminal.  Objects using the terminal may register handlers, this is the case for the LineReader, or advanced applications such as the nano editor, less pager, etc...

You may want to set an interrupt signal handler while "executing" the command.  You could intercept it and try to interrupt the command for example...

[Brad Wood]

You may want to set an interrupt signal handler while "executing" the command.  You could intercept it and try to interrupt the command for example...

Interesting.  So EndOfFileException and UserInterruptException are thrown only while readLine() is executing, but I can register my own handler that will get called ANY time? Does it run in its own thread?  I'm not sure I have a use ATM for this but if I'm understanding you correctly, it seems useful.  For example, if my CLI is downloading a large file, I could try and interrupt the process from this separate thread instead of the user having to sit and wait for the entire thing to finish?

Thanks!

~Brad

Developer Advocate

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

[Brad Wood]

Can you help clarify for me, what it would look like to register my own handler and do my handlers fire in a separate thread that can be invoked even when readLine() is not currently executing?  

[Guillaume Nodet]

Only a single signal handler is active for a given signal.

When the LineReader starts reading a line, it will set its own handler for the INT, WINCH, CONT signals and will restore the previous one before returning from the readLine() call.

On Tue, Dec 26, 2017 at 7:59 PM, Brad Wood <bdw...@gmail.com> wrote:

Can you help clarify for me, what it would look like to register my own handler and do my handlers fire in a separate thread that can be invoked even when readLine() is not currently executing?  

--

[Brad Wood]

Thank you for the additional information, however it seems my specific questions still are open:

1. How can I register a custom handler of my own? (code samples, docs, examples)
   
2. Will my custom handler fire even when readLine() is not being executed?

Thanks!

~Brad

Developer Advocate

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

[Guillaume Nodet]

On Tue, Dec 26, 2017 at 9:15 PM, Brad Wood <bdw...@gmail.com> wrote:

Thank you for the additional information, however it seems my specific questions still are open:

1. How can I register a custom handler of my own? (code samples, docs, examples)
   

Signals are used in various places: Less, Nano, Ssh, Tmux, TTop.

Those are good real use-cases.

 

2. Will my custom handler fire even when readLine() is not being executed?

As I said, the LineReader will set its own handler at the beginning of the readLine() call and will restore it before exiting. So the answer is yes.

[Brad Wood]

Ok, thanks.  I've made a ticket to circle back to this and see about adding some better Ctrl-C support to allow a user to try and interrupt a command that's in the middle of executing via a custom handler.  

[Guillaume Nodet]

Fwiw, if you really want to, you could also implement foreground / background jobs (the ending & + ^Z).

This is done with signal support:

 https://github.com/apache/felix/blob/trunk/gogo/jline/src/main/java/org/apache/felix/gogo/jline/Shell.java#L451-L462 

On Tue, Dec 26, 2017 at 10:46 PM, Brad Wood <bdw...@gmail.com> wrote:

Ok, thanks.  I've made a ticket to circle back to this and see about adding some better Ctrl-C support to allow a user to try and interrupt a command that's in the middle of executing via a custom handler.  

--