If you kill a python process with SIGINT (e.g. control-c), it catches 
the signal, and raises a KeyboardInterrupt. If the KeyboardInterrupt 
propagates to the top level, python exits. However, it exits with a 
result of 1, not a result of SIGINT. This means that if you run 
python in a shell script, the script will not properly exit on C-c.

When exiting because of a KeyboardInterrupt, python ought to 
reraise the SIGINT, as follows, so that the exit code is correct for 
the caller:
        signal(SIGINT, SIG_DFL);
        kill(getpid(), SIGINT);

See also http://www.cons.org/cracauer/sigint.html for a more 
detailed discussion on the topic.

Logged In: YES 
user_id=6656

Feel like writing a patch?

I'll close this in a couple of weeks unless someone wants it kept open.

Here's a patch that implements this behavior.  It is too late in the 3.2 beta/rc cycle to get this into 3.2.  Consider it for 3.3.  I'd like a review.

Looks good to me.  Do you need the TODO(gps)'s in there after implementing the behavior described?

- should KeyboardInterrupt always exit with SIGINT, or only if it was actually raised by a signal handler?
- if _Py_UnhandledKeyboardInterrupt is defined in Modules/main.c but used in Python/pythonrun.c, can't it cause linker errors when embedding Python?
- please use PEP 8 (testKeyboardInterruptSignalExit -> test_some_long_name)

I wonder whether there is a precedent of some system mapping SIGINT to
an exception. We could probably learn something from them.

> - should KeyboardInterrupt always exit with SIGINT, or only if it was
> actually raised by a signal handler?

IMO, if we give the illusion that the interpreter was actually killed,
we should equate KeyboardInterrupt with SIGINT; any uncaught
KeyboardInterrupt should consequently always lead to raising SIGINT.

> IMO, if we give the illusion that the interpreter was actually killed,
> we should equate KeyboardInterrupt with SIGINT; any uncaught
> KeyboardInterrupt should consequently always lead to raising SIGINT.

Agreed.  Plus that is easier to implement and what I did.

I'll remove the left over TODO(gps) comments (oops) before this is
ever committed. I'm waiting until after 3.2 is released unless the
release manager jumps in and says otherwise.  remaining items:

 1. I need to add a second test case that writes the code to a file
and launches a subprocess executing that file instead of using -c
given that they are different code paths that each need testing.  For
variety I'll probably make that one send an actual SIGINT to the child
process rather than having it raise KeyboardInterrupt.

 2. The tests probably needs a decorator to limit their execution to posix.

 3. Do the signal and kill calls also need to be conditional based on
platform or is the function I put them in already posix-only?  If
necessary I'll protect them with #ifdefs so they don't break a windows
build.

+        kill(getpid(), SIGINT);

kill() doesn't exist on Windows: use raise() which is more portable and doesn't require a PID argument.

We may need to do something on Windows for console applications: see SetConsoleCtrlHandler(),
http://msdn.microsoft.com/en-us/library/ms686016(v=vs.85).aspx

+        self.assertEqual(returncode, -signal.SIGINT,
+                         "not a SIGINT exit code. process stderr:\n%s" % stderr)

I don't think that such test can pass on Windows.