Bug: ctrl+break is not ctrl+c #1489

Closed
opened 2026-01-30 22:28:32 +00:00 by claunia · 7 comments
Owner

Originally created by @Cologler on GitHub (Jun 3, 2019).

Originally assigned to: @zadjii-msft on GitHub.

Steps to reproduce

  1. open windows terminal for cmd.exe
  2. execute command ping 8.8.8.8 -t
  3. press ctrl+break

Expected behavior

windows terminal show ctrl+break

Actual behavior

windows terminal show ctrl+c

Originally created by @Cologler on GitHub (Jun 3, 2019). Originally assigned to: @zadjii-msft on GitHub. # Steps to reproduce 1. open windows terminal for cmd.exe 1. execute command `ping 8.8.8.8 -t` 1. press `ctrl`+`break` # Expected behavior windows terminal show ctrl+break # Actual behavior windows terminal show ctrl+c
Author
Owner

@Cologler commented on GitHub (Jun 3, 2019):

ctrl+break and ctrl+c have a different meanings in ping command.

Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
            [-r count] [-s count] [[-j host-list] | [-k host-list]]
            [-w timeout] [-R] [-S srcaddr] [-c compartment] [-p]
            [-4] [-6] target_name

Options:
    -t             Ping the specified host until stopped.
                   To see statistics and continue - type Control-Break;
                   To stop - type Control-C.
@Cologler commented on GitHub (Jun 3, 2019): ctrl+break and ctrl+c have a different meanings in ping command. ``` txt Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS] [-r count] [-s count] [[-j host-list] | [-k host-list]] [-w timeout] [-R] [-S srcaddr] [-c compartment] [-p] [-4] [-6] target_name Options: -t Ping the specified host until stopped. To see statistics and continue - type Control-Break; To stop - type Control-C. ```
Author
Owner

@wi-ry commented on GitHub (Jun 12, 2019):

See attached. Ctrl+Break works in standard command prompt, however Windows Terminal processes Ctrl+Break as pressing Ctrl+C:
Capture

@wi-ry commented on GitHub (Jun 12, 2019): See attached. Ctrl+Break works in standard command prompt, however Windows Terminal processes Ctrl+Break as pressing Ctrl+C: ![Capture](https://user-images.githubusercontent.com/9650258/59328846-4a42e780-8ca2-11e9-9051-d383366ef364.JPG)
Author
Owner

@szalapski commented on GitHub (Feb 21, 2020):

Is there a workaround? How do I send an actual Ctrl+Break?

@szalapski commented on GitHub (Feb 21, 2020): Is there a workaround? How do I send an actual Ctrl+Break?
Author
Owner

@int19h commented on GitHub (Mar 6, 2020):

This is affecting some apps that only respect Ctrl+Break. For example, it appears to be impossible to stop a tox+pytest test run without closing the tab, or killing the process from another one.

@int19h commented on GitHub (Mar 6, 2020): This is affecting some apps that only respect Ctrl+Break. For example, it appears to be impossible to stop a tox+pytest test run without closing the tab, or killing the process from another one.
Author
Owner

@zadjii-msft commented on GitHub (Mar 31, 2020):

Alright, I finally dug out my keyboard that has a break key to investigate this.

In conhost

ctrl+break

Down: 1 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x28
Down: 0 Repeat: 1 KeyCode: 0x3 ScanCode: 0x46 Char: ^C (0x3) KeyState: 0x128
Down: 0 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x20

ctrl+c

Down: 1 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x28
Down: 0 Repeat: 1 KeyCode: 0x43 ScanCode: 0x2e Char: ^C (0x3) KeyState: 0x28
Down: 0 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x20

In gnome-terminal, xterm

This is the part that gets interesting: ctrl+break isn't actually encoded as anything. I can't find any documentation that ctrl+break should send anything in VT - presumably because that's supposed to send a signal of some kind, not a key that the client app can understand.

Conclusions

Since conpty at this point is limited to things that can be encoded in VT, there's no way for us to be able to send a sequence specifically for ctrl+break. #879 is our megathread that's tracking adding support for additional keys that currently aren't encodable in VT - I'm going to parent this bug to that thread.

@zadjii-msft commented on GitHub (Mar 31, 2020): Alright, I finally dug out my keyboard that has a break key to investigate this. #### In `conhost` <kbd>ctrl+break</kbd> ``` Down: 1 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x28 Down: 0 Repeat: 1 KeyCode: 0x3 ScanCode: 0x46 Char: ^C (0x3) KeyState: 0x128 Down: 0 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x20 ``` <kbd>ctrl+c</kbd> ``` Down: 1 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x28 Down: 0 Repeat: 1 KeyCode: 0x43 ScanCode: 0x2e Char: ^C (0x3) KeyState: 0x28 Down: 0 Repeat: 1 KeyCode: 0x11 ScanCode: 0x1d Char: \0 (0x0) KeyState: 0x20 ``` #### In `gnome-terminal`, `xterm` This is the part that gets interesting: <kbd>ctrl+break</kbd> isn't actually encoded as _anything_. I can't find any documentation that <kbd>ctrl+break</kbd> should send anything in VT - presumably because that's supposed to send a signal of some kind, not a key that the client app can understand. #### Conclusions Since conpty at this point is limited to things that can be encoded in VT, there's no way for us to be able to send a sequence specifically for <kbd>ctrl+break</kbd>. #879 is our megathread that's tracking adding support for additional keys that currently aren't encodable in VT - I'm going to parent this bug to that thread.
Author
Owner

@lempax commented on GitHub (Apr 15, 2020):

I also experienced this issue on v0.10.781.0. I do hope this will be fixed as I am already accustomed to command prompt using this feature. Thanks.

@lempax commented on GitHub (Apr 15, 2020): I also experienced this issue on v0.10.781.0. I do hope this will be fixed as I am already accustomed to command prompt using this feature. Thanks.
Author
Owner

@ghost commented on GitHub (Jun 18, 2020):

:tada:This issue was addressed in #6309, which has now been successfully released as Windows Terminal Preview v1.1.1671.0.🎉

Handy links:

@ghost commented on GitHub (Jun 18, 2020): :tada:This issue was addressed in #6309, which has now been successfully released as `Windows Terminal Preview v1.1.1671.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.1.1671.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#1489