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

Cannot use stream-based I/O to ConPTY/Console and receive WINDOWS_BUFFER_SIZE_EVENT simultaneously #598

New Issue
Closed
opened 2026-01-30 21:56:30 +00:00 by claunia · 15 comments
claunia commented 2026-01-30 21:56:30 +00:00
Owner
Copy Link

Originally created by @oising on GitHub (Mar 25, 2019).

Microsoft Windows [Version 10.0.18362.1]

To monitor console buffer resize events (and viewport resize events in more recent builds), ReadConsoleInput must be used to look for INPUT_BUFFER events with an event type of 4 ( WINDOW_BUFFER_SIZE_EVENT ).

My problem is that when I open a pseudoconsole session for a new cmd.exe process and I want to use bidirectional VT codes (stream based) for stdin/stdout for maximum cross platform portability. That is to say, I don't want to use the windows console APIs because they are windows specific. This seems to make it very difficult - without gag-inducing and complex task synchronization - to watch for resize events at the same time. When stdin/stdout are flushed, any INPUT_BUFFER records in ReadConsoleInput are too, including WINDOWS_BUFFER_SIZE_EVENT records.

VT allows capturing mouse movement - or at least it should in the future since ConPTY doesn't seem to forward mouse coords/actions yet, but there is no equivalent VT sequence for resizes of the viewport. Here's some demo/repro code:

My specific NuGet dependencies for the repro are:

  • Vanara.PInvoke.Kernel32 / 2.3.4
  • Pipelines.Sockets.Unofficial / 2.0.7
using System;
using System.IO;
using System.IO.Pipelines;
using System.Runtime.InteropServices;
using System.Threading;
using System.Threading.Tasks;

using Pipelines.Sockets.Unofficial;
using Vanara.PInvoke;

namespace resizetest
{
    internal class Program
    {
        private static async Task Main(string[] args)
        {
            // run for 30 seconds
            const int timeout = 30000;

            var source = new CancellationTokenSource(timeout); // 30 seconds
            var token = source.Token;
            var handle = Kernel32.GetStdHandle(Kernel32.StdHandleType.STD_INPUT_HANDLE);
            
            Kernel32.CONSOLE_MODE mode = default;

            if (!Kernel32.GetConsoleMode(handle, ref mode))
            {
                throw Marshal.GetExceptionForHR(Marshal.GetLastWin32Error());
            }
            
            mode |= Kernel32.CONSOLE_MODE.ENABLE_WINDOW_INPUT;
            mode |= Kernel32.CONSOLE_MODE.ENABLE_VIRTUAL_TERMINAL_INPUT;
            mode &= ~Kernel32.CONSOLE_MODE.ENABLE_MOUSE_INPUT;

            if (!Kernel32.SetConsoleMode(handle, mode))
            {
                throw Marshal.GetExceptionForHR(Marshal.GetLastWin32Error());
            }

            Task drainStdin = Task.Run(async () =>
            {
                // UNCOMMENT THESE LINES TO ENABLE CAPTURE OF RESIZE EVENTS
                //await Task.Delay(timeout, token);
                //return;

                Stream stdin = Console.OpenStandardInput();
                PipeReader reader = StreamConnection.GetReader(stdin);

                while (!token.IsCancellationRequested)
                {
                    var result = await reader.ReadAsync(token);
                    if (result.IsCanceled || result.IsCompleted)
                    {
                        break;
                    }

                    // do stuff...

                    Console.WriteLine("stdin: read {0} byte(s)", result.Buffer.Length);
                }
            }, token);

            Task readInputBuffer = Task.Run(async () =>
            {
                while (!token.IsCancellationRequested)
                {
                    await Task.Delay(10, token);

                    if (!Kernel32.GetNumberOfConsoleInputEvents(handle, out var count))
                    {
                        throw Marshal.GetExceptionForHR(Marshal.GetLastWin32Error());
                    }

                    if (count > 0)
                    {
                        var buffer = new Kernel32.INPUT_RECORD[count];

                        if (!Kernel32.ReadConsoleInput(handle, buffer, count, out var total)) {
                            throw Marshal.GetExceptionForHR(Marshal.GetLastWin32Error());
                        }

                        if (total > 0)
                        {
                            // TODO: de-bounce and only send last resize? 
                            for (int index = 0; index < total; index++)
                            {
                                var record = buffer[index];

                                Console.WriteLine("type: {0}", record.EventType);

                                if (record.EventType == Kernel32.EVENT_TYPE.WINDOW_BUFFER_SIZE_EVENT) // resize
                                {
                                    var size = record.Event.WindowBufferSizeEvent.dwSize;
                                    Console.WriteLine("buffer: resize to {{{0}, {1}}}", size.X, size.Y);
                                }
                            }
                        }
                    }
                }

            }, token);

            Console.WriteLine("Running");

            try
            {
                await Task.WhenAll(readInputBuffer, drainStdin);
            }
            catch (OperationCanceledException)
            {
                // timeout
            }

            Console.WriteLine("press any key...");
            Console.ReadKey(true);

        }
    }
}

TL;DR -- it's very hard, if not impossible, to watch for viewport resizing and also use a pure VT implementation (no console API).

Solution? I'd suggest draining the input buffer if streaming but leaving resize, menu, mouse (if enabled) events etc. This may be a memory leak (but probably fixed max, circular buffer etc) if the default behaviour changed, so I guess it should be opt-in.

Originally created by @oising on GitHub (Mar 25, 2019). Microsoft Windows [Version 10.0.18362.1] To monitor console buffer resize events (and viewport resize events in more recent builds), `ReadConsoleInput` must be used to look for `INPUT_BUFFER` events with an event type of 4 ( `WINDOW_BUFFER_SIZE_EVENT` ). My problem is that when I open a pseudoconsole session for a new cmd.exe process and I want to use bidirectional VT codes (stream based) for stdin/stdout for maximum cross platform portability. That is to say, I don't want to use the windows console APIs because they are windows specific. This seems to make it very difficult - without gag-inducing and complex task synchronization - to watch for resize events at the same time. When stdin/stdout are flushed, any `INPUT_BUFFER` records in `ReadConsoleInput` are too, including `WINDOWS_BUFFER_SIZE_EVENT` records. VT allows capturing mouse movement - or at least it should in the future since ConPTY doesn't seem to forward mouse coords/actions yet, but there is no equivalent VT sequence for resizes of the viewport. Here's some demo/repro code: My specific NuGet dependencies for the repro are: - Vanara.PInvoke.Kernel32 / 2.3.4 - Pipelines.Sockets.Unofficial / 2.0.7 ``` using System; using System.IO; using System.IO.Pipelines; using System.Runtime.InteropServices; using System.Threading; using System.Threading.Tasks; using Pipelines.Sockets.Unofficial; using Vanara.PInvoke; namespace resizetest { internal class Program { private static async Task Main(string[] args) { // run for 30 seconds const int timeout = 30000; var source = new CancellationTokenSource(timeout); // 30 seconds var token = source.Token; var handle = Kernel32.GetStdHandle(Kernel32.StdHandleType.STD_INPUT_HANDLE); Kernel32.CONSOLE_MODE mode = default; if (!Kernel32.GetConsoleMode(handle, ref mode)) { throw Marshal.GetExceptionForHR(Marshal.GetLastWin32Error()); } mode |= Kernel32.CONSOLE_MODE.ENABLE_WINDOW_INPUT; mode |= Kernel32.CONSOLE_MODE.ENABLE_VIRTUAL_TERMINAL_INPUT; mode &= ~Kernel32.CONSOLE_MODE.ENABLE_MOUSE_INPUT; if (!Kernel32.SetConsoleMode(handle, mode)) { throw Marshal.GetExceptionForHR(Marshal.GetLastWin32Error()); } Task drainStdin = Task.Run(async () => { // UNCOMMENT THESE LINES TO ENABLE CAPTURE OF RESIZE EVENTS //await Task.Delay(timeout, token); //return; Stream stdin = Console.OpenStandardInput(); PipeReader reader = StreamConnection.GetReader(stdin); while (!token.IsCancellationRequested) { var result = await reader.ReadAsync(token); if (result.IsCanceled || result.IsCompleted) { break; } // do stuff... Console.WriteLine("stdin: read {0} byte(s)", result.Buffer.Length); } }, token); Task readInputBuffer = Task.Run(async () => { while (!token.IsCancellationRequested) { await Task.Delay(10, token); if (!Kernel32.GetNumberOfConsoleInputEvents(handle, out var count)) { throw Marshal.GetExceptionForHR(Marshal.GetLastWin32Error()); } if (count > 0) { var buffer = new Kernel32.INPUT_RECORD[count]; if (!Kernel32.ReadConsoleInput(handle, buffer, count, out var total)) { throw Marshal.GetExceptionForHR(Marshal.GetLastWin32Error()); } if (total > 0) { // TODO: de-bounce and only send last resize? for (int index = 0; index < total; index++) { var record = buffer[index]; Console.WriteLine("type: {0}", record.EventType); if (record.EventType == Kernel32.EVENT_TYPE.WINDOW_BUFFER_SIZE_EVENT) // resize { var size = record.Event.WindowBufferSizeEvent.dwSize; Console.WriteLine("buffer: resize to {{{0}, {1}}}", size.X, size.Y); } } } } } }, token); Console.WriteLine("Running"); try { await Task.WhenAll(readInputBuffer, drainStdin); } catch (OperationCanceledException) { // timeout } Console.WriteLine("press any key..."); Console.ReadKey(true); } } } ``` TL;DR -- it's very hard, if not impossible, to watch for viewport resizing and also use a pure VT implementation (no console API). Solution? I'd suggest draining the input buffer if streaming but leaving resize, menu, mouse (if enabled) events etc. This may be a memory leak (but probably fixed max, circular buffer etc) if the default behaviour changed, so I guess it should be opt-in.
claunia added the Product-ConhostIssue-QuestionResolution-AnsweredArea-Server labels 2026-01-30 21:56:30 +00:00
claunia commented 2026-01-30 21:56:31 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (Mar 25, 2019):

Just to put this in context, I'm writing a terminal multiplexer under coreclr (2.2). When I've bound conhost to a cmd/wsl/pwsh subprocess, I can't resize the virtual terminal in response to the user resizing conhost.

@oising commented on GitHub (Mar 25, 2019): Just to put this in context, I'm writing a terminal multiplexer under coreclr (2.2). When I've bound conhost to a cmd/wsl/pwsh subprocess, I can't resize the virtual terminal in response to the user resizing conhost.
claunia commented 2026-01-30 21:56:31 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Mar 27, 2019):

@oising to be clear, are you trying to be a client application or a server application?

Your title is mixing both ConPTY and the usage of the classic console API, which implies to me that you're trying to be a client application and a server (console window host) to yourself at the same time.

Or is it that you're trying to be a client application but speaking 99% VT on WriteFile and only using the minimal amount of other Windows client-APIs as possible?

EDIT: I'm dumb. Let me re-read this and try again.

@miniksa commented on GitHub (Mar 27, 2019): @oising to be clear, are you trying to be a client application or a server application? Your title is mixing both ConPTY and the usage of the classic console API, which implies to me that you're trying to be a client application and a server (console window host) to yourself at the same time. Or is it that you're trying to be a client application but speaking 99% VT on WriteFile and only using the minimal amount of other Windows client-APIs as possible? EDIT: I'm dumb. Let me re-read this and try again.
claunia commented 2026-01-30 21:56:31 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Mar 27, 2019):

OK so you've got this:

(A) Conhost in standard window visible mode <----> (B) Multiplexer application <------> (C) Conhost in ConPty mode <-----> (D) Client application

A is the server on top displaying stuff.
B is the client of the A server and is simultaneously holding the server end of the C ConPty.
The client end of the C ConPty is going to the D client application.

D is probably speaking classic Win32 to the C conhost in ConPTY mode.
The C conhost in ConPTY is then presumably speaking VT out to B (and vice versa).
The B multiplexer on startup right after attaching to A tells the A handles that it wants the virtual terminal output and input modes so it can get/give information in those formats over the STDIN and STDOUT pipes to make things easy with the information it's receiving from the other side from C.

And I think your problem is that between A and B, it's difficult or nigh impossible to know when the A window has resized and have an event come into B in a format that is easy to consume.

Sound right?

@miniksa commented on GitHub (Mar 27, 2019): OK so you've got this: (A) Conhost in standard window visible mode <----> (B) Multiplexer application <------> (C) Conhost in ConPty mode <-----> (D) Client application A is the server on top displaying stuff. B is the client of the A server and is simultaneously holding the server end of the C ConPty. The client end of the C ConPty is going to the D client application. D is probably speaking classic Win32 to the C conhost in ConPTY mode. The C conhost in ConPTY is then presumably speaking VT out to B (and vice versa). The B multiplexer on startup right after attaching to A tells the A handles that it wants the virtual terminal output and input modes so it can get/give information in those formats over the `STDIN` and `STDOUT` pipes to make things easy with the information it's receiving from the other side from C. And I think your problem is that between A and B, it's difficult or nigh impossible to know when the A window has resized and have an event come into B in a format that is easy to consume. Sound right?
claunia commented 2026-01-30 21:56:31 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (Mar 27, 2019):

@miniksa Right. Between A (physical, visible conhost window) and B (multiplexer watching conpty C running D, and relaying stdin/stdout between D and A.)

If I resize the physical window (A), it seems impossible to capture that informational event while streaming stdin/stdout to and from (A) and (D).

D is speaking classic win32 yes, but since it's conpty, it doesn't really matter.

@oising commented on GitHub (Mar 27, 2019): @miniksa Right. Between A (physical, visible conhost window) and B (multiplexer watching conpty C running D, and relaying stdin/stdout between D and A.) If I resize the physical window (A), it seems impossible to capture that informational event while streaming stdin/stdout to and from (A) and (D). D is speaking classic win32 yes, but since it's conpty, it doesn't really matter.
claunia commented 2026-01-30 21:56:32 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (Mar 27, 2019):

It seems that the moment you start reading from Console.OpenInputStream() then ReadConsoleInput stops receiving any data. Now obviously this makes sense at first glance, since you're gonna use one or the other but unfortunately resize events are only consumable from the latter.

(update: I invited you to my private repo hosting the full code if you're interested in taking a look for more context)

@oising commented on GitHub (Mar 27, 2019): It seems that the moment you start reading from Console.OpenInputStream() then ReadConsoleInput stops receiving any data. Now obviously this makes sense at first glance, since you're gonna use one or the other but unfortunately resize events are only consumable from the latter. (update: I invited you to my private repo hosting the full code if you're interested in taking a look for more context)
claunia commented 2026-01-30 21:56:32 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Mar 27, 2019):

I think that the .NET abstractions here cause inadvertant flushes. If you're trying to do something advanced like this, I would strongly discourage using System.Console and recommend you just P/Invoke the Win32 APIs instead.

I'll have to give your private repo and the rest of this a more thorough scrub tomorrow morning. I have a few other things to get through today. I might also need @zadjii-msft to get back to work to confer with him on the state of resize as he's been in that space more recently than I have (he's just on vacation this week, due back on Monday.)

@miniksa commented on GitHub (Mar 27, 2019): I think that the .NET abstractions here cause inadvertant flushes. If you're trying to do something advanced like this, I would strongly discourage using `System.Console` and recommend you just P/Invoke the Win32 APIs instead. I'll have to give your private repo and the rest of this a more thorough scrub tomorrow morning. I have a few other things to get through today. I might also need @zadjii-msft to get back to work to confer with him on the state of resize as he's been in that space more recently than I have (he's just on vacation this week, due back on Monday.)
claunia commented 2026-01-30 21:56:32 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (Mar 28, 2019):

I dug into FX already and there was nothing there that stood out initially. Internally the console PAL layer uses ReadConsole or ReadFile, depending on whether or not the handle is redirected. Buried halfway down the ReadConsole docs, there's the following ominous statement:

If the input buffer contains input events other than keyboard events (such as mouse events or window-resizing events), they are discarded. Those events can only be read by using the ReadConsoleInput function.

Trying to force ReadFile and figure out the magic sequences was shutdown by the notes for ENABLE_WINDOW_INPUT:

User interactions that change the size of the console screen buffer are reported in the console's input buffer. Information about these events can be read from the input buffer by applications using the ReadConsoleInput function, but not by those using ReadFile or ReadConsole.

I suppose this shouldn't be a surprise since ReadConsole and ReadConsoleInput drain the same buffer. My vision of having a nice, clean symmetrical usage of pipelines for stdin/stdout has now been crushed.

Blergh.

@oising commented on GitHub (Mar 28, 2019): I dug into FX already and there was nothing there that stood out initially. Internally the console PAL layer uses `ReadConsole` or `ReadFile`, depending on whether or not the handle is redirected. Buried halfway down the `ReadConsole` docs, there's the following ominous statement: > If the input buffer contains input events other than keyboard events (such as mouse events or window-resizing events), **they are discarded**. Those events can only be read by using the ReadConsoleInput function. Trying to force `ReadFile` and figure out the magic sequences was shutdown by the notes for `ENABLE_WINDOW_INPUT`: > User interactions that change the size of the console screen buffer are reported in the console's input buffer. Information about these events can be read from the input buffer by applications using the ReadConsoleInput function, **but not by those using ReadFile or ReadConsole**. I suppose this shouldn't be a surprise since `ReadConsole` and `ReadConsoleInput` drain the same buffer. My vision of having a nice, clean symmetrical usage of pipelines for stdin/stdout has now been crushed. Blergh.
claunia commented 2026-01-30 21:56:32 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Mar 28, 2019):

Yes, sorry, uhhh... When the calls are serviced, it's the same queue underlying both APIs inside the conhost.exe process. So if you try to ReadFile a thing (or ReadConsole) and it hits the queue and a non KEY_EVENT is sitting there, it's discarded and moves onto the next event.

Also, I have a massive pile of e-mail in my inbox this morning so I'm not remotely closer to looking at your private repro that you shared with me. Please bear with me. I'll try to get to it.

@miniksa commented on GitHub (Mar 28, 2019): Yes, sorry, uhhh... When the calls are serviced, it's the same queue underlying both APIs inside the `conhost.exe` process. So if you try to `ReadFile` a thing (or `ReadConsole`) and it hits the queue and a non `KEY_EVENT` is sitting there, it's discarded and moves onto the next event. Also, I have a massive pile of e-mail in my inbox this morning so I'm not remotely closer to looking at your private repro that you shared with me. Please bear with me. I'll try to get to it.
claunia commented 2026-01-30 21:56:32 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (Mar 28, 2019):

@miniksa Don't stress man over the private repo. It's something you might enjoy reading through to get an idea how someone is trying to do something more advanced than a sample app. In your own time!

@oising commented on GitHub (Mar 28, 2019): @miniksa Don't stress man over the private repo. It's something you might enjoy reading through to get an idea how someone is trying to do something more advanced than a sample app. In your own time!
claunia commented 2026-01-30 21:56:33 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (Mar 28, 2019):

Okay, so it looks like I've no choice but to wrap ReadConsoleInput as a Stream, just as the console wraps ReadConsole and come up with some way to side channel the other events. Not trivial, but not impossible either. You guys can either close this, or keep it open for tracking if you see this as an API improvement possibility.

@oising commented on GitHub (Mar 28, 2019): Okay, so it looks like I've no choice but to wrap `ReadConsoleInput` as a `Stream`, just as the console wraps `ReadConsole` and come up with some way to side channel the other events. Not trivial, but not impossible either. You guys can either close this, or keep it open for tracking if you see this as an API improvement possibility.
claunia commented 2026-01-30 21:56:33 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Mar 29, 2019):

This is one of the classes of issue I want to solve when we get time to do something about #281. Might leave it open.

@miniksa commented on GitHub (Mar 29, 2019): This is one of the classes of issue I want to solve when we get time to do something about #281. Might leave it open.
claunia commented 2026-01-30 21:56:33 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (Apr 11, 2019):

So I managed to hack together a prototype WindowsConsoleInputStream class that accepts a BlockingCollection<INPUT_RECORD> for side-channel event dispatching (MENU_EVENT, MOUSE_EVENT, WINDOWS_BUFFER_SIZE_EVENT etc) while preserving byte array stream semantics for KEY_EVENT. This lets us wrap a PipeReader around it for nice and simple async IO on stdin/stdou with ConPTY, while watching for viewport changes asynchronously too. So, it's doable!

@oising commented on GitHub (Apr 11, 2019): So I managed to hack together a prototype `WindowsConsoleInputStream` class that accepts a `BlockingCollection<INPUT_RECORD>` for side-channel event dispatching (MENU_EVENT, MOUSE_EVENT, WINDOWS_BUFFER_SIZE_EVENT etc) while preserving byte array stream semantics for KEY_EVENT. This lets us wrap a PipeReader around it for nice and simple async IO on stdin/stdou with ConPTY, while watching for viewport changes asynchronously too. So, it's doable!
claunia commented 2026-01-30 21:56:34 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Apr 11, 2019):

Excellent to hear. If you have a useful reusable component that helps make this easier, I'd be happy to accept a pull into this repo in the tools directory so we can have it for others to use as well.

@miniksa commented on GitHub (Apr 11, 2019): Excellent to hear. If you have a useful reusable component that helps make this easier, I'd be happy to accept a pull into this repo in the tools directory so we can have it for others to use as well.
claunia commented 2026-01-30 21:56:34 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (Apr 21, 2019):

@miniksa Done - https://github.com/Microsoft/console/pull/414

@oising commented on GitHub (Apr 21, 2019): @miniksa Done - https://github.com/Microsoft/console/pull/414
claunia commented 2026-01-30 21:56:34 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (May 18, 2019):

I think this is answered, done, and relatively over with for now. Any further calculations on getting the event out will have to do with that one that I said "I need to make this a deliverable for size events".

@miniksa commented on GitHub (May 18, 2019): I think this is answered, done, and relatively over with for now. Any further calculations on getting the event out will have to do with that one that I said "I need to make this a deliverable for size events".
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 Area-Server Issue-Question Product-Conhost 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#598
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?