This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients Drekin, abarry, eryksun, tim.golden, troyhirni, vstinner
Date 2016-03-11.12:58:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
This problem has come up in several issues now (see issue 25376 and issue 26531). I'm adding a patch for Python 3.6 to call ReadConsoleA instead of fgets in PyOS_Readline. This fixes Ctrl+C and EOF handling in Windows 10 for both the interactive shell and the built-in input() function. 

As noted previously, changes to the console in Windows 8 and 10 introduced a bug in ReadFile. It no longer sets the last error to ERROR_OPERATION_ABORTED (995) when a console read is interrupted by Ctrl+C or Ctrl+Break. This is a problem for the current implementation of PyOS_Readline, which calls ReadFile indirectly via C fgets. 

This bug can be avoided by calling ReadConsoleA instead of fgets when stdin is a console. Note that isatty() is insufficient to detect the console, since it's true for all character devices, such as NUL. I instead call GetConsoleMode to check for a console handle.

I'm also looking into modifying Modules/signalmodule.c to set _PyOS_SigintEvent() when SIGBREAK is tripped, which matters when there's a non-default SIGBREAK handler. Also, PyErr_CheckSignals is a logical place to reset the event. Actually, it seems to me that everywhere in signalmodule.c where the signal flag is untripped should reset the event, in which case there should be an untrip_signal() to match trip_signal().
Date User Action Args
2016-03-11 12:58:31eryksunsetrecipients: + eryksun, vstinner, tim.golden, Drekin, abarry, troyhirni
2016-03-11 12:58:31eryksunsetmessageid: <>
2016-03-11 12:58:31eryksunlinkissue18597 messages
2016-03-11 12:58:31eryksuncreate