[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Block Ctrl+S while running Python script at Windows console?

On 3/18/19, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
> On Mon, 18 Mar 2019 14:38:40 -0400, "Malcolm Greene" <python at bdurham.com>
> declaimed the following:
>>Wondering if there's a way to have my Python scripts ignore these Ctrl+S
>> signals or if this behavior is outside of my Python script's control. If
>> there's a way to disable this behavior under Windows 10/Windows Server
>> 2016, I'm open to that as well.
> 	<ctrl-s>/<ctrl-q> (XOFF/XON) are traditional terminal control codes to
> stop/start transmission. The behavior is baked into the console being used.

The Windows console does not really implement XOFF (DC3, Ctrl+S) and
XON (DC1, Ctrl+Q) terminal behavior. In line-input mode, it implements
Ctrl+S as equivalent to pressing the pause key (i.e. VK_PAUSE, which
has the same numeric value as DC3), so it's meant to be familiar to
people who are used to working in terminals. But, in contrast to a
terminal emulator, there is no requirement to press Ctrl+Q (i.e. DC1)
to resume. Almost any key suffices to resume the console, except for
the pause key and modifiers (Ctrl, Alt, Shift). In particular,
pressing Ctrl+S again, as the original poster did, will resume the
Windows console, but it would not resume a terminal emulator.

If enabled, the console's extended editing keys feature overrides the
default pause behavior of Ctrl+S. It can be enabled via the console's
ExtendedEditKey registry value, or in the defaults and properties
dialogs by enabling "extended text selection keys". Disabling it also
disables immediate access to the console's new text selection keys
such as Shift+Arrows, in which case we have to first enter mark mode
via Ctrl+M.

The default extended-editing keymap doesn't define anything for
Ctrl+S, so it's just a DC3 (0x13) character. In principle the extended
editing keys can be customized to map Ctrl+S to a virtual key such as
VK_PAUSE (i.e. retain the default behavior), but, as far as I know,
the binary format of the console's ExtendedEditKeyCustom registry
value is not documented.

Regardless of the extended editing keys setting, we can always read
Ctrl+S via msvcrt.getwch(), since it disables line-input mode.