Tcl Source Code

Background: Windows allows Ctrl-C, Ctrl-Break etc. to be trapped by the application via the SetConsoleCtrlHandler call. Although Tcl itself does not support this in the core, extensions such as twapi do. However, a feature/bug/quirk in the tclWinConsole.c:ReadConsoleBytes function makes this trapping ineffective. As documented in MSDN, a Ctrl-C results in the Windows ReadConsole call returning successfully but with 0 bytes read. This gets funneled up the Tcl channel system as EOF on stdin and consequently the REPL loop exits.

The proposed change would be to change ReadConsoleBytes to detect this (GetLastError() returns ERROR_OPERATION_ABORTED) and simply repost the ReadConsole.

There will be no observed change in the default behaviour because the default OS handler (run in a separate thread) will still exit the process on a Ctrl-C. However, applications that use extensions to trap Ctrl-C by replacing the default handler will work as expected.

The proposed change is in the Windows-specific code and will not affect other platforms.

Reference: http://stackoverflow.com/questions/27903208/tcl-and-ctrl-c-in-windows-console/27904696#27904696

Fix in [4368d9eefc] looks fine to me, so closing.

status?

Committed fix in checkin [4368d9eefc]

This change looks good to me. Please go ahead and either provide a patch or just commit it. I will be happy to apply the patch and/or to test it.

Changed to Bug because rethinking the issue, treating the Ctrl-C as EOF seems just wrong.