Ctrl+Break behaves in cmd not as expected #7030

Closed
opened 2026-01-31 00:53:20 +00:00 by claunia · 3 comments
Owner

Originally created by @schlamar on GitHub (Mar 20, 2020).

Environment

Windows build number: Microsoft Windows [Version 10.0.18363.720]
Windows Terminal version (if applicable): Version: 0.10.761.0

Usually a Ctrl+C behaves different than Ctrl+Break in a cmd console.

But in Windows Terminal Ctrl+Break behaves like Ctrl+C.

For example you can reproduce this with Python by running in cmd

py -c "import time; time.sleep(60)"

Expected behavior

Ctrl+C --> KeyboardInterrupt
Ctrl+Break --> Program quits without KeyobardInterrupt

This is the default behavior in standalone cmd.exe.

Actual behavior

Ctrl+C --> KeyboardInterrupt
Ctrl+Break --> KeyboardInterrupt

Originally created by @schlamar on GitHub (Mar 20, 2020). # Environment ```none Windows build number: Microsoft Windows [Version 10.0.18363.720] Windows Terminal version (if applicable): Version: 0.10.761.0 ``` Usually a Ctrl+C behaves different than Ctrl+Break in a cmd console. But in Windows Terminal Ctrl+Break behaves like Ctrl+C. For example you can reproduce this with Python by running in cmd py -c "import time; time.sleep(60)" # Expected behavior Ctrl+C --> KeyboardInterrupt Ctrl+Break --> Program quits **without** KeyobardInterrupt This is the default behavior in standalone cmd.exe. # Actual behavior Ctrl+C --> KeyboardInterrupt Ctrl+Break --> KeyboardInterrupt
claunia added the Resolution-Duplicate label 2026-01-31 00:53:20 +00:00
Author
Owner

@schlamar commented on GitHub (Mar 20, 2020):

It is possible that this is a regression from the 0.10 update because I haven't noticed this before.

@schlamar commented on GitHub (Mar 20, 2020): It is possible that this is a regression from the 0.10 update because I haven't noticed this before.
Author
Owner

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

Thanks for the report! This is actually already being tracked by another issue on our repo - please refer to #1119 for more discussion.

/dup #1119

@zadjii-msft commented on GitHub (Mar 20, 2020): Thanks for the report! This is actually already being tracked by another issue on our repo - please refer to #1119 for more discussion. /dup #1119
Author
Owner

@ghost commented on GitHub (Mar 20, 2020):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Mar 20, 2020): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#7030