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

copying text for CLI program kills program #17693

New Issue
Closed
opened 2026-01-31 05:50:28 +00:00 by claunia · 13 comments
claunia commented 2026-01-31 05:50:28 +00:00
Owner
Copy Link

Originally created by @jredfox on GitHub (Jun 12, 2022).

Windows Terminal version

No response

Windows build number

No response

Other Software

java or any cli program

Steps to reproduce

steps to reproduce. create a simple java program a dummy program for testing

public static void main(String[] args)
{
   while(true);
}

run

wt new-tab java -jar myprogram.jar

hit control+c

notice the app is dead. the user was simply trying to copy and paste previous output and the program died. right clicking to copy something in wt isn't possible and most people are use to using control+c for copy as it is everywhere else in windows.

Expected Behavior

app stays alive and text is copied to the clipboard

Actual Behavior

app dies

Solution

use a different keybind to close the process like control+fn+c or control+alt+c

Originally created by @jredfox on GitHub (Jun 12, 2022). ### Windows Terminal version _No response_ ### Windows build number _No response_ ### Other Software java or any cli program ### Steps to reproduce steps to reproduce. create a simple java program a dummy program for testing ```java public static void main(String[] args) { while(true); } ```` run ``` wt new-tab java -jar myprogram.jar ``` hit control+c notice the app is dead. the user was simply trying to copy and paste previous output and the program died. right clicking to copy something in wt isn't possible and most people are use to using control+c for copy as it is everywhere else in windows. ### Expected Behavior app stays alive and text is copied to the clipboard ### Actual Behavior app dies ### Solution use a different keybind to close the process like control+fn+c or control+alt+c
claunia commented 2026-01-31 05:50:29 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 13, 2022):

  • Do you have Ctrl+C bound to copy in your settings/?

  • Did you select text before hitting Ctrl+C?

  • right clicking to copy something in wt isn't possible

    It uh, very much should be. Does that not work with text selected?

  • use a different keybind to close the process

    Ctrl+C is a pretty standard signal for interrupting the current commandline process across platforms. We've also shipped Ctrl+Shift+C as a standard copy keybinding for this reason.

This sounds by-design to me. When there's no text selected, then pressing the copy action's keybinding will fail to copy (because there was nothing to copy), and fall through the to the CLI application running in the Terminal to be able to process it.

@zadjii-msft commented on GitHub (Jun 13, 2022): * Do you have <kbd>Ctrl+C</kbd> bound to `copy` in your settings/? * Did you select text before hitting <kbd>Ctrl+C</kbd>? * > right clicking to copy something in wt isn't possible It uh, very much should be. Does that not work with text selected? * > use a different keybind to close the process Ctrl+C is a pretty standard signal for interrupting the current commandline process across platforms. We've also shipped <kbd>Ctrl+Shift+C</kbd> as a standard `copy` keybinding for this reason. This sounds by-design to me. When there's no text selected, then pressing the `copy` action's keybinding will fail to copy (because there was nothing to copy), and fall through the to the CLI application running in the Terminal to be able to process it.
claunia commented 2026-01-31 05:50:29 +00:00
Author
Owner
Copy Link

@jredfox commented on GitHub (Jun 13, 2022):

Control c is copy everywhere else in windows but a simple mis key and your program dies this is the issue. It needs to get fixed every other app in history doesn't shutdown with control+c why should terminal?

@jredfox commented on GitHub (Jun 13, 2022): Control c is copy everywhere else in windows but a simple mis key and your program dies this is the issue. It needs to get fixed every other app in history doesn't shutdown with control+c why should terminal?
claunia commented 2026-01-31 05:50:30 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 13, 2022):

Sure, but every commandline application in history does. Hence why we've predicated the behavior on having a selection. It's a relatively graceful way to support both copying and terminating on Ctrl+C. So long as you've actually made a selection, Ctrl+C won't send the ^C to the running app.

@zadjii-msft commented on GitHub (Jun 13, 2022): Sure, but every _commandline_ application in history _does_. Hence why we've predicated the behavior on having a selection. It's a relatively graceful way to support both copying and terminating on <kbd>Ctrl+C</kbd>. So long as you've actually made a selection, <kbd>Ctrl+C</kbd> won't send the `^C` to the running app.
claunia commented 2026-01-31 05:50:30 +00:00
Author
Owner
Copy Link

@jredfox commented on GitHub (Jun 13, 2022):

Well I suggest changing it it's the opposite over user friendly. If people actually started to use cli programs again people would quit because of this issue. Imagine a person who barley knows control c and control v because of Minecraft tries to run a Java jar or exe file through win terminal and it keeps randomly closing.

@jredfox commented on GitHub (Jun 13, 2022): Well I suggest changing it it's the opposite over user friendly. If people actually started to use cli programs again people would quit because of this issue. Imagine a person who barley knows control c and control v because of Minecraft tries to run a Java jar or exe file through win terminal and it keeps randomly closing.
claunia commented 2026-01-31 05:50:30 +00:00
Author
Owner
Copy Link

@naikrovek commented on GitHub (Jun 13, 2022):

@jredfox the current behavior is correct. In command-line applications, CTRL+C kills the running process, and doesn’t copy highlighted text. Highlighting with the mouse alone is what copies to the clipboard (with text selected, right-clicking will copy and deselect in openconsole.exe as it always has.).

(In Windows Terminal, for me, right-click always pastes, and I don’t remember now if this is something I’ve changed over the years.)

experienced users will definitely not be surprised with this behavior.

@naikrovek commented on GitHub (Jun 13, 2022): @jredfox the current behavior is correct. In command-line applications, CTRL+C kills the running process, and doesn’t copy highlighted text. Highlighting with the mouse alone is what copies to the clipboard (with text selected, right-clicking will copy and deselect in openconsole.exe as it always has.). (In Windows Terminal, for me, right-click always pastes, and I don’t remember now if this is something I’ve changed over the years.) experienced users will definitely not be surprised with this behavior.
claunia commented 2026-01-31 05:50:30 +00:00
Author
Owner
Copy Link

@jredfox commented on GitHub (Jun 14, 2022):

Everyone disagrees with you ask any user that uses other apps if control+c should shutdown their program instead of copy because text wasn't "highlighted" and it's the "users" fault on why you have presses the key twice and the keybind conflicts with copy. This is exactly the opposite of what user friendlyness is and it's called an issue. Regardless of being a bug it's an issue not with the user. If this never gets fixed then it's the reason why people stopped using cli even if their app didn't require anything besides commands or worse having a bad crappy cli that has most of the features not working per app

This is the exact opposite of what people expect from Microsoft do you want to give Microsoft a bad name for reasons why not to use a cli all because this issue doesn't get fixed

@jredfox commented on GitHub (Jun 14, 2022): Everyone disagrees with you ask any user that uses other apps if control+c should shutdown their program instead of copy because text wasn't "highlighted" and it's the "users" fault on why you have presses the key twice and the keybind conflicts with copy. This is exactly the opposite of what user friendlyness is and it's called an issue. Regardless of being a bug it's an issue not with the user. If this never gets fixed then it's the reason why people stopped using cli even if their app didn't require anything besides commands or worse having a bad crappy cli that has most of the features not working per app This is the exact opposite of what people expect from Microsoft do you want to give Microsoft a bad name for reasons why not to use a cli all because this issue doesn't get fixed
claunia commented 2026-01-31 05:50:31 +00:00
Author
Owner
Copy Link

@naikrovek commented on GitHub (Jun 14, 2022):

every other capable command line user I know understands what CTRL+C does and doesn't do.

none of them want what you are asking for.

the plain command prompt going back all the way to DOS worked the same way - CTRL+C killed the foreground process. once copying and pasting became a thing, and command.com (or cmd.exe, I forget which had it first) supported the QuickEdit feature, AND that was turned on, selecting with the mouse, then pushing ENTER copied whatever was selected. if QuickEdit was off, which was the default, then you had to press alt+space or click the upper-right icon of the window and select copy, then highlight the text you want to copy, then push ENTER.

CTRL+C has always killed the foreground process in the terminal or command line. I don't think CTRL+C has ever been "copy" in command.com or cmd.exe in my entire career. I've been using MS operating systems since 1991.

Microsoft aren't going to accommodate your unique expectation when there is an editor built in to Terminal that lets you customize what keystrokes do, and when they do it.

so, you go do that. make ctrl+c always copy and find some other way to be able to tell the foreground process to go away. the actions editor in Terminal will allow this, and if it doesn't, the settings.json file will.

the rest of us will continue using terminals exactly as we have for 20+ years.

@naikrovek commented on GitHub (Jun 14, 2022): every other capable command line user I know understands what CTRL+C does and doesn't do. none of them want what you are asking for. the plain command prompt going back all the way to DOS worked the same way - CTRL+C killed the foreground process. once copying and pasting became a thing, and command.com (or cmd.exe, I forget which had it first) supported the QuickEdit feature, AND that was turned on, selecting with the mouse, then pushing ENTER copied whatever was selected. if QuickEdit was off, which was the default, then you had to press alt+space or click the upper-right icon of the window and select copy, then highlight the text you want to copy, then push ENTER. CTRL+C has *always* killed the foreground process in the terminal or command line. I don't think CTRL+C has ever been "copy" in command.com or cmd.exe in my entire career. I've been using MS operating systems since 1991. Microsoft aren't going to accommodate your *unique* expectation when there is an editor built in to Terminal that lets you customize what keystrokes do, and when they do it. so, you go do that. make ctrl+c always copy and find some other way to be able to tell the foreground process to go away. the actions editor in Terminal will allow this, and if it doesn't, the settings.json file will. the rest of us will continue using terminals exactly as we have for 20+ years.
claunia commented 2026-01-31 05:50:31 +00:00
Author
Owner
Copy Link

@jredfox commented on GitHub (Jun 14, 2022):

Just because it's been a issue for windows users for 20 years does not mean it's not valid. It's nothing to do with accommodate me it's wt itself.

As suggested by officials here they can change the keybind to control + shift + c. Other terminals do not terminate with control c as they realize they don't want this behavior like Linux they make you right click then copy or paste. I get it was there for legacy reasons but as soon as they added copy paste as a standard they should have changed it it's a conflicting keybind

@jredfox commented on GitHub (Jun 14, 2022): Just because it's been a issue for windows users for 20 years does not mean it's not valid. It's nothing to do with accommodate me it's wt itself. As suggested by officials here they can change the keybind to control + shift + c. Other terminals do not terminate with control c as they realize they don't want this behavior like Linux they make you right click then copy or paste. I get it was there for legacy reasons but as soon as they added copy paste as a standard they should have changed it it's a conflicting keybind
claunia commented 2026-01-31 05:50:31 +00:00
Author
Owner
Copy Link

@naikrovek commented on GitHub (Jun 14, 2022):

There is already a keybinding for copying text using CTRL+SHIFT+C and it is there by default.

so what should Windows Terminal do when connected to a Linux machine via SSH, no text is selected, the user wants to kill the runaway Linux command line application, and they press CTRL+C to do so?

@naikrovek commented on GitHub (Jun 14, 2022): There is already a keybinding for copying text using CTRL+SHIFT+C and it is there by default. so what should Windows Terminal do when connected to a Linux machine via SSH, no text is selected, the user wants to kill the runaway Linux command line application, and they press CTRL+C to do so?
claunia commented 2026-01-31 05:50:31 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 15, 2022):

Yea, Ctrl+C as SIGINT is something that long predates the Terminal, and we're not going to be able to change. I remember first learning the commandline and thinking it was a little weird myself. Ten years later now, and it feels like second nature to expect commandline keybindings to just be a little different. At least the "Ctrl+C with a selection is still copy" seems like a pretty successful middle ground.

At least we don't have copy/paste bound to something insane like yy / pp or Alt+w/Ctrl+y😄

@zadjii-msft commented on GitHub (Jun 15, 2022): Yea, Ctrl+C as SIGINT is something that long predates the Terminal, and we're not going to be able to change. I remember first learning the commandline and thinking it was a little weird myself. Ten years later now, and it feels like second nature to expect commandline keybindings to just be a little different. At least the "<kbd>Ctrl+C</kbd> with a selection is still copy" seems like a pretty successful middle ground. At least we don't have copy/paste bound to something insane like <kbd>y</kbd><kbd>y</kbd> / <kbd>p</kbd><kbd>p</kbd> or <kbd>Alt+w</kbd>/<kbd>Ctrl+y</kbd>😄
claunia commented 2026-01-31 05:50:31 +00:00
Author
Owner
Copy Link

@jredfox commented on GitHub (Jul 16, 2022):

I will say this though you guys will change your mind though in the coming months. the main reason why I pointed this as a valid issue is I am making a library that is cross platform and supports alot of terminals. in one line you will be able to create a new UI with profiling native support and also things like ANSI colors. it won't be directed from me though it will get noticed through conhost and then reported again by someone else from microsoft or another company

@jredfox commented on GitHub (Jul 16, 2022): I will say this though you guys will change your mind though in the coming months. the main reason why I pointed this as a valid issue is I am making a library that is cross platform and supports alot of terminals. in one line you will be able to create a new UI with profiling native support and also things like ANSI colors. it won't be directed from me though it will get noticed through conhost and then reported again by someone else from microsoft or another company
claunia commented 2026-01-31 05:50:32 +00:00
Author
Owner
Copy Link

@naikrovek commented on GitHub (Jul 25, 2022):

Ok.

@naikrovek commented on GitHub (Jul 25, 2022): Ok.
claunia commented 2026-01-31 05:50:32 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 25, 2022):

@jredfox You're right -- this is a valid concern -- but it's unfortunately just too late. The default interrupt character on every Windows device and Linux, macOS, BSD and any UNIX derivative produced in the past 35 years is Ctrl+C. That Windows has elected to use Ctrl+C in other graphical applications to indicate Copy for an equivalent amount of time is likewise unfortunate, but is also an immovable historical choice.

Other terminals do not terminate with control c as they realize they don't want this behavior like Linux they make you right click then copy or paste.

Unfortunately, they all do. Ctrl+C isn't handled by the terminal in any specific way, it's passed through to the line discipline driver and processed by the kernel. It can be rebound on a tty-by-tty basis using stty intr, but it generally is not.

If you're producing a cross-platform TUI library, you can switch the terminal or console host into raw input mode and handle Ctrl+C yourself and in so doing avoid termination, but that won't make it act as Copy unless you write some platform- and display-server-specific glue code.

We're bound by the choices of our forebears here. Sorry.

@DHowett commented on GitHub (Jul 25, 2022): @jredfox You're right -- this is a valid concern -- but it's unfortunately just too late. The default interrupt character on every Windows device and Linux, macOS, BSD and any UNIX derivative produced in the past 35 years is <kbd>Ctrl+C</kbd>. That Windows has elected to use <kbd>Ctrl+C</kbd> in other graphical applications to indicate _Copy_ for an equivalent amount of time is likewise unfortunate, but is also an immovable historical choice. > Other terminals do not terminate with control c as they realize they don't want this behavior like Linux they make you right click then copy or paste. Unfortunately, they all do. <kbd>Ctrl+C</kbd> isn't handled by the terminal in any specific way, it's passed through to the line discipline driver and processed by the kernel. It can be rebound on a tty-by-tty basis using `stty intr`, but it generally is not. If you're producing a cross-platform TUI library, you can switch the terminal or console host into raw input mode and handle <kbd>Ctrl+C</kbd> yourself and in so doing avoid termination, but that won't make it act as Copy unless you write some platform- and display-server-specific glue code. We're bound by the choices of our forebears here. Sorry.
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-Bug Needs-Attention Needs-Tag-Fix Needs-Triage Resolution-Won't-Fix
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#17693
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?