Issue1313

It seems that 'except KeyboardInterrupt' or even plain 'except' is not
enough to catch ctrl-c with Jython. This is unfortunate because it makes
it prevents stopping applications started from the command line gracefully. 

This problem can be tested with the attached script. When I execute it
with Jython (tested both with 2.2 and 2.5b3) on my OS X and press ctrl-c
it simply quits without even a traceback. With CPython it prints both
'KeyboardInterrupt' and 'Bye!' before exiting cleanly.

Issue 1746106 is probably related to this problem:
http://bugs.jython.org/issue1746106

The same behaviour can be observed on Linux as well. If CTRL-C is
entered at the python command prompt, a KeyboardInterrupt is shown and
the command prompt appears again. This is handy when I am in the middle
of editing a line and just needs to get back to the prompt. How ever, if
the same is done in Jython, the interpreter exits. I tested with 2.5b3.
I am unable to add a new version to the tracker at the moment so I am
not selecting any version.

I'm currently using the following code as workaround:

import signal

def intHandler(signum, frame):
    print "user pressed ctrl-c"
    raise KeyboardInterrupt()

# Set the signal handler
signal.signal(signal.SIGINT, intHandler)

This installs a special handler for the interrupt signal, which raises a
KeyboardInterrupt.

I tested the workaround suggested by marc on 2.5.1 rc 3 but it didn't
work. After adding those lines to the attached ctrlc.py script, I wasn't
able to stop the execution at all. Pressing ctrl-c just gave the
following traceback every time I hit it and even 'kill -9' left a
defunct java process.

^CException in thread "SIGINT handler" Traceback (most recent call last):
  File "/home/peke/Prog/jython2.5.1rc3/Lib/signal.py", line 113, in handle
    self.action(signal.getNumber(), None)
  File "Lataukset/ctrlc.py", line 5, in intHandler
    raise KeyboardInterrupt()
KeyboardInterrupt


The reason I'm interested about this issue is that I'd like to implement
a possibility to stop Robot Framework test execution gracefully from the
command line: http://code.google.com/p/robotframework/issues/detail?id=108

It's not that straightforward to implement this like CPython does. Creating a signal handler that handles SIGINT is easy enough, but Java's signal support will call the handler in a brand new thread -- what you're really asking for is for Jython to always call the handler in the main thread like CPython does, interrupting any operation in progress

Any movement on this problem? I am still looking for a way to interrupt the interpreter.

This is an important problem, as I expect (proper) programs to quit nicely after hitting Ctrl-C.  E.g. 'finally' and 'with' statements do what they promise to do and clean up correspondingly.  Instead, Ctrl-C just kills Jython scripts outright.

Hi everyone, 
i have worked on this problem several hours and now finally got solution.

I am using jython-2.5.3b1 library in my code. There should be attached my workaround code for this problem. It is complete Jython console, available to interrupt current code with SIGINT - worked for me 100%.

Short description of solution:
I use sighandler with few modifications as Marc suggested.
In sighandler I call to sys._jy_interpreter.interrupt(thp) where thp is ThreadState of main execution thread - here is need to differ between thread handling signals and main execution thread. Thus we need store ThreadState somewhere to reach it from different thread - sighandler.

Such call will cause Java Exception java.lang.Error and InteractiveConsole terminates. BUT when we start new InteractiveConsole, python state will remain same, thus environment objects will be still available as before SIGINT sending.

IMHO my workaround code could be easily adapted to fix this issue in jython, if needed. I leave this for others since I know Jython project only a few weeks.

Please consult attached workaround code. After start, it automatically registers own SIGINT handler. You can test it with this piece of code:
def fib( n ):
   if n == 0 or n == 1:
      return n
   else:
      return fib( n - 1 ) + fib( n - 2 )

Try running fib(10), this should work correctly. Next try to run fib(1000), this should freeze for a quite long time. Send SIGINT with CTRL-C. Code is interrupted and new instance of console is launched. Now you can verify that you can still call fib(5) correctly, as before freeze and console restart.

There is little problem with this solution - what if you really want to exit console? In this situation we can program not to start console again.

Hope this helps.

I think that this is to do with the JLineConsole.

If you change the "python.console" property in the registry file to "org.python.util.InteractiveConsole", i.e

python.console=org.python.util.InteractiveConsole

The ctrl-c starts working fine.

If you leave it at the default JLine console (http://jline.sourceforge.net/) then ctrl-c seems to get treated as a normal character (shows up as a heart symbol on my windows command line).

I suggest you try a different console class until this is fixed.

I'll look into how we can address this.

In the meantime, I would be interested in reports to see if changing the console class fixes the issue on various platforms.

In my case I run scripts non-interactively.  Would changing console class affect anything in this case?

By the way, I also use the workaround of installing a custom handler for signal.SIGINT now, to avoid ctrl-C killing the program without cleanup.   Custom handler sets an internal flag to True, then I have to periodically test (yes, manually, and this sucks!) it and raise a KeyboardInterrupt if it's set.

In my case it's very important as I rollback database changes and drop some temporary tables on exceptions.  With stock Jython ctrl-C leaves those tables existing, spoiling future runs.

No, the console type wouldn't affect non interactive usage

Duplicate of #1270