starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Method to escape a hung process #13092

New Issue
Closed
opened 2026-01-31 03:33:41 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 03:33:41 +00:00
Owner
Copy Link

Originally created by @armordog on GitHub (Mar 18, 2021).

Description of the new feature/enhancement

A keyboard shortcut to kill the current process (or background it).

This would be useful because, in git bash, nodejs processes with watchers frequently stop responding when I hit ctrl+c.

That is,

  • process is running
  • I hit ctrl+c -- normally it would stop watching and print a new prompt, but frequently...
  • a new blank line is printed to the console
  • the console is unresponsive for over a minute
  • then it's fine

There's nothing I can do other than
a) wait around doing nothing
b) close the entire tab and open a new one

Maybe there's already a way to do this and I don't know what it is?

Originally created by @armordog on GitHub (Mar 18, 2021). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement A keyboard shortcut to kill the current process (or background it). This would be useful because, in git bash, nodejs processes with watchers frequently stop responding when I hit `ctrl+c`. That is, - process is running - I hit `ctrl+c` -- normally it would stop watching and print a new prompt, but frequently... - a new blank line is printed to the console - the console is unresponsive for over a minute - then it's fine There's nothing I can do other than a) wait around doing nothing b) close the entire tab and open a new one Maybe there's already a way to do this and I don't know what it is?
claunia commented 2026-01-31 03:33:43 +00:00
Author
Owner
Copy Link

@Nacimota commented on GitHub (Mar 19, 2021):

Surely this would be more of a shell issue (unless you're saying the terminal itself is hanging as well)? I'm not certain there would be a simple way for the terminal to determine which specific process it is that you want to kill. I imagine it gets more complicated when you throw SSH, WSL, etc. into the mix as well.

The problem with Ctrl+C is that it can be (and often is) intercepted by the process. I think in Windows you can also use Ctrl+Break, which (to my knowledge) can't be intercepted. I'm sure there are *nix equivalents but they probably vary depending on configuration.

@Nacimota commented on GitHub (Mar 19, 2021): Surely this would be more of a shell issue (unless you're saying the terminal itself is hanging as well)? I'm not certain there would be a simple way for the terminal to determine which specific process it is that you want to kill. I imagine it gets more complicated when you throw SSH, WSL, etc. into the mix as well. The problem with Ctrl+C is that it can be (and often is) intercepted by the process. I think in Windows you can also use Ctrl+Break, which (to my knowledge) can't be intercepted. I'm sure there are *nix equivalents but they probably vary depending on configuration.
claunia commented 2026-01-31 03:33:43 +00:00
Author
Owner
Copy Link

@armordog commented on GitHub (Mar 19, 2021):

Thanks for responding.
I'm just not sure what to do.
I know a lot of times ctrl+z backgrounds a process but that does nothing with Terminal + Git Bash (I have no way of knowing which is supposed to handle that).

There's no way for me to know where it's hanging.

I'll try ctrl+break next time.

@armordog commented on GitHub (Mar 19, 2021): Thanks for responding. I'm just not sure what to do. I know a lot of times `ctrl+z` backgrounds a process but that does nothing with Terminal + Git Bash (I have no way of knowing which is supposed to handle that). There's no way for me to know _where_ it's hanging. I'll try `ctrl+break` next time.
claunia commented 2026-01-31 03:33:44 +00:00
Author
Owner
Copy Link

@eryksun commented on GitHub (Mar 19, 2021):

The problem with Ctrl+C is that it can be (and often is) intercepted by the process. I think in Windows you can also use Ctrl+Break, which (to my knowledge) can't be intercepted.

The console session's input stream can be set to unprocessed mode (i.e. the ENABLE_PROCESSED_INPUT flag isn't set). In this mode, when the user presses Ctrl+C, the console writes ETX (0x03, end of text) to the input buffer instead of sending CTRL_C_EVENT (cancel) to attached processes. Even if a cancel event is sent, it may be ignored by a process. Calling SetConsoleCtrlHandler(NULL, TRUE) sets a flag in the current process to ignore Ctrl+C events, which gets inherited by child processes.

In contrast, CTRL_BREAK_EVENT is always generated when Ctrl+Break is pressed, and it cannot be ignored at the process level. That does not mean, however, that it always terminates all processes in a console session. If the event isn't handled, i.e. none of the registered handler routines returns TRUE, then the default handler is called, which exits the process. But if it's handled, the way it's handled depends on the application. For example, the CMD shell does not exit when Ctrl+Break is pressed. Doing so would be dysfunctional, since users usually want to break back to the shell, not to kill the entire console session.

The C runtime maps the console cancel and break events to the SIGINT and SIGBREAK 'signals'. If the signal handler isn't set to SIG_DFL (default), then it's possible that it effectively ignores the event -- obviously so if it's set to SIG_IGN (ignore). The MSYS2 runtime that Git bash uses probably does something similar for the console cancel and break events, and bash probably ignores them in the interactive shell.

@eryksun commented on GitHub (Mar 19, 2021): > The problem with Ctrl+C is that it can be (and often is) intercepted by the process. I think in Windows you can also use Ctrl+Break, which (to my knowledge) can't be intercepted. The console session's input stream can be set to unprocessed mode (i.e. the `ENABLE_PROCESSED_INPUT` flag isn't set). In this mode, when the user presses Ctrl+C, the console writes ETX (0x03, end of text) to the input buffer instead of sending `CTRL_C_EVENT` (cancel) to attached processes. Even if a cancel event is sent, it may be ignored by a process. Calling `SetConsoleCtrlHandler(NULL, TRUE)` sets a flag in the current process to ignore Ctrl+C events, which gets inherited by child processes. In contrast, `CTRL_BREAK_EVENT` is always generated when Ctrl+Break is pressed, and it cannot be ignored at the process level. That does not mean, however, that it always terminates all processes in a console session. If the event isn't handled, i.e. none of the registered handler routines returns `TRUE`, then the default handler is called, which exits the process. But if it's handled, the way it's handled depends on the application. For example, the CMD shell does not exit when Ctrl+Break is pressed. Doing so would be dysfunctional, since users usually want to break back to the shell, not to kill the entire console session. The C runtime maps the console cancel and break events to the `SIGINT` and `SIGBREAK` 'signals'. If the signal handler isn't set to `SIG_DFL` (default), then it's possible that it effectively ignores the event -- obviously so if it's set to `SIG_IGN` (ignore). The MSYS2 runtime that Git bash uses probably does something similar for the console cancel and break events, and bash probably ignores them in the interactive shell.
claunia commented 2026-01-31 03:33:44 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 19, 2021):

I'd suspect that the same behavior repros even in the vintage console. I'm fully expecting this one to be caused by the client application, and totally out of our control 😕

@zadjii-msft commented on GitHub (Mar 19, 2021): I'd suspect that the same behavior repros even in the vintage console. I'm fully expecting this one to be caused by the client application, and totally out of our control 😕
claunia commented 2026-01-31 03:33:44 +00:00
Author
Owner
Copy Link

@armordog commented on GitHub (Mar 19, 2021):

I really appreciate all the feedback.

I don't understand exactly how Terminal interfaces with Git Bash but am I correct in understanding that keypresses like ctrl+z, ctrl+\, ctrl+break, etc are not trapped by Terminal and will be sent to the Git Bash instance?

If so, I guess I need to look elsewhere for a solution.

Thanks.

@armordog commented on GitHub (Mar 19, 2021): I really appreciate all the feedback. I don't understand exactly how Terminal interfaces with Git Bash but am I correct in understanding that keypresses like `ctrl+z`, `ctrl+\`, `ctrl+break`, etc are not trapped by Terminal and will be sent to the Git Bash instance? If so, I guess I need to look elsewhere for a solution. Thanks.
claunia commented 2026-01-31 03:33:44 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 22, 2021):

Happy to help!

@zadjii-msft commented on GitHub (Mar 22, 2021): Happy to help!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Feature Issue-Question Needs-Attention Needs-Tag-Fix Needs-Triage Resolution-Answered
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#13092
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?