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

In Terminal "command prompt", it seems there's no shortcut to select current command's text? Ctrl-a not working #20027

New Issue
Open
opened 2026-01-31 07:01:13 +00:00 by claunia · 11 comments
claunia commented 2026-01-31 07:01:13 +00:00
Owner
Copy Link

Originally created by @carehart on GitHub (Jun 3, 2023).

Is there a reason ctrl-a doesn't allow selecting all the text of the current command line input, such as to then copy it to the clipboard? For now, using ctrl-a does nothing but append ^A to the end of that input. I'm referring here to the Terminal "command prompt" view.

Note that in the Powershell view, or the traditional Windows command prompt (conhost), ctrl-a does this task, so some of us have it trained into our fingers. :-) Since it seems that key combination is unused (in the "command prompt' view), has it been considered for this task?

Yes of course there is the shortcut to "select all", ctrl+shift+a, but that selects the entire terminal (input and output). I'm asking about just the command input. (For any who don't understand what I mean here, simply type a command to run it, then hit up-arrow to retrieve it. I'm asking how to select that command--or any other past one, without using the mouse, such as to copy it to the clipboard.)

And to be clear, I find no feature in the "command palette" to do this ("select all" for the displayed command, only). So for now one must use their mouse to select such a command, which is why I seek a shortcut alternative.

Again, ctrl-a works this way in the Terminal powershell view and the traditional command prompt, and it's not being used in the Terminal Command prompt. Could it be? Or am I missing something? (And I looked, but I didn't see any open issues that seemed related.)

Originally created by @carehart on GitHub (Jun 3, 2023). Is there a reason ctrl-a doesn't allow selecting all the text of the current command line input, such as to then copy it to the clipboard? For now, using ctrl-a does nothing but append ^A to the end of that input. I'm referring here to the Terminal "command prompt" view. Note that in the Powershell view, or the traditional Windows command prompt (conhost), ctrl-a does this task, so some of us have it trained into our fingers. :-) Since it seems that key combination is unused (in the "command prompt' view), has it been considered for this task? Yes of course there is the shortcut to "select all", ctrl+shift+a, but that selects the entire terminal (input and output). I'm asking about just the command input. (For any who don't understand what I mean here, simply type a command to run it, then hit up-arrow to retrieve it. I'm asking how to select that command--or any other past one, without using the mouse, such as to copy it to the clipboard.) And to be clear, I find no feature in the "command palette" to do this ("select all" for the displayed command, only). So for now one must use their mouse to select such a command, which is why I seek a shortcut alternative. Again, ctrl-a works this way in the Terminal powershell view and the traditional command prompt, and it's not being used in the Terminal Command prompt. Could it be? Or am I missing something? (And I looked, but I didn't see any open issues that seemed related.)
claunia added the Issue-FeatureArea-InteractionProduct-Conpty labels 2026-01-31 07:01:13 +00:00
claunia commented 2026-01-31 07:01:14 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 5, 2023):

Hey! With the switch to VT sequences for communication, the Terminal is now more reliant on the shell (cmd/powershell/...) to provide such input line handling, which is why it works in PowerShell. I believe your issue is a duplicate of #10645. I'm personally not entirely sure if duplicating it with #715 was a 100% fit, but mark mode (Ctrl+Shift+M by default - it can be changed) does at least partially do the trick, even if it doesn't do Ctrl+A the way it used to. Ctrl+Shift+Left/Right does work as expected.

@lhecker commented on GitHub (Jun 5, 2023): Hey! With the switch to VT sequences for communication, the Terminal is now more reliant on the shell (cmd/powershell/...) to provide such input line handling, which is why it works in PowerShell. I believe your issue is a duplicate of #10645. I'm personally not entirely sure if duplicating it with #715 was a 100% fit, but mark mode (Ctrl+Shift+M by default - it can be changed) does at least partially do the trick, even if it doesn't do Ctrl+A the way it used to. Ctrl+Shift+Left/Right does work as expected.
claunia commented 2026-01-31 07:01:14 +00:00
Author
Owner
Copy Link

@carehart commented on GitHub (Jun 5, 2023):

Thanks, @lhecker. #10645 is indeed asking the same thing. Sorry I missed that. As for #715, well, that seems to go bit far afield of this one matter.

Also, you propose that "Ctrl+Shift+Left/Right does work as expected." If you mean in Terminal compared to conhost, I'd say that's not so: in conhost, that WOULD select the text (word by word) in the command line (which would be better than nothing), but instead in the Terminal command prompt it ONLY moves the cursor word by word (the shift is not doing anything, though indeed it could and should).

Finally, you open saying that "the Terminal is now more reliant on the shell (cmd/powershell/...) to provide such input line handling, which is why it works in PowerShell", and that would indeed BE encouraging...if only it were so, in this respect of Terminal getting from cmd/conhost this handling of ctrl-a or ctrl-shift-left/right. :-)

I suspect you know or perceive something more (perhaps from #715) that leads you to think there's a clue to follow for perhaps solving this. I'll leave that in the hands of those interested in the topic, and especially familiar with all the inner workings. I am not at all, but am just a user. Indeed, I keep trying to use terminal as the default but I keep running into little things like this that push me back to not using it.

But I am indeed trying to "make the world a better place" by sharing the observations here. I appreciate that in most open source projects there are a lot of folks like me and few folks like you--and we dearly appreciate you guys doing the heavy lifting! :-)

@carehart commented on GitHub (Jun 5, 2023): Thanks, @lhecker. #10645 is indeed asking the same thing. Sorry I missed that. As for #715, well, that seems to go bit far afield of this one matter. Also, you propose that "_Ctrl+Shift+Left/Right does work as expected._" If you mean in Terminal compared to conhost, I'd say that's not so: in conhost, that WOULD **select** the text (word by word) in the command line (which would be better than nothing), but instead in the Terminal command prompt it ONLY moves the cursor word by word (the shift is not doing anything, though indeed it could and should). Finally, you open saying that "_the Terminal is now more reliant on the shell (cmd/powershell/...) to provide such input line handling, which is why it works in PowerShell_", and that would indeed BE encouraging...if only it were so, in this respect of Terminal getting from cmd/conhost this handling of ctrl-a or ctrl-shift-left/right. :-) I suspect you know or perceive something more (perhaps from #715) that leads you to think there's a clue to follow for perhaps solving this. I'll leave that in the hands of those interested in the topic, and especially familiar with all the inner workings. I am not at all, but am just a user. Indeed, I keep trying to use terminal as the default but I keep running into little things like this that push me back to not using it. But I am indeed trying to "make the world a better place" by sharing the observations here. I appreciate that in most open source projects there are a lot of folks like me and few folks like you--and we dearly appreciate you guys doing the heavy lifting! :-)
claunia commented 2026-01-31 07:01:15 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 6, 2023):

FWIW the Ctrl+A handling in PowerShell is done by PsReadline (a powershell module), not the terminal / console itself. The "selection" created by Ctrl+A in pwsh is entirely something that pwsh itself is maintaining, not something more fundamental.

Command Prompt doesn't use psreadline (obviously). It relies on the "cooked read" functionality of the console APIs themselves. Theoretically, if we did want to fix this for cmd.exe, the place to do so would be in the cooked read handler in the console. That would add this for both cmd.exe and any other console apps that use cooked reads for input (e.g. the python REPL).

That of course, would also be a "selection" that the Terminal couldn't know about - that would all be internal to the console itself. That "selection" would be entirely independent of the end terminal, so thinks like mark mode wouldn't operate on that selection, which would be wEiRd.

Alas, we actually can't really make changes like that to cmd.exe.

Maybe there's some way we could:

  • have terminal request "CookedReadV2" from the console, so that Terminal itself could opt in to new commandline handling, while conhost remains opted out
  • have conpty transmit "selection" state to the end terminal (and vice versa)

</notes from trying to fall asleep>

I think probably the better solution here is something built on top of shell integration.

@zadjii-msft commented on GitHub (Jun 6, 2023): FWIW the Ctrl+A handling in PowerShell is done by PsReadline (a powershell module), not the terminal / console itself. The "selection" created by Ctrl+A in pwsh is entirely something that pwsh itself is maintaining, not something more fundamental. Command Prompt doesn't use psreadline (obviously). It relies on the "cooked read" functionality of the console APIs themselves. Theoretically, if we _did_ want to fix this for cmd.exe, the place to do so would be in the cooked read handler in the console. That would add this for both cmd.exe and any other console apps that use cooked reads for input (e.g. the python REPL). That of course, would also be a "selection" that the Terminal couldn't know about - that would all be internal to the console itself. That "selection" would be entirely independent of the end terminal, so thinks like mark mode wouldn't operate on that selection, which would be wEiRd. Alas, we actually [can't really make changes like that to cmd.exe](https://github.com/microsoft/terminal/blob/main/doc/Niksa.md#why-do-we-avoid-changing-cmdexe). Maybe there's some way we could: * have terminal request "CookedReadV2" from the console, so that Terminal itself could opt in to new commandline handling, while conhost remains opted out * have conpty transmit "selection" state to the end terminal (and vice versa) \</notes from trying to fall asleep> ---- I think probably the better solution here is something built on top of [shell integration](https://github.com/MicrosoftDocs/terminal/blob/main/TerminalDocs/tutorials/shell-integration.md).
claunia commented 2026-01-31 07:01:15 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 6, 2023):

FWIW the Ctrl+A handling in PowerShell is done by PsReadline (a powershell module), not the terminal / console itself. The "selection" created by Ctrl+A in pwsh is entirely something that pwsh itself is maintaining, not something more fundamental.

Command Prompt doesn't use psreadline (obviously). It relies on the "cooked read" functionality of the console APIs themselves. Theoretically, if we did want to fix this for cmd.exe, the place to do so would be in the cooked read handler in the console. That would add this for both cmd.exe and any other console apps that use cooked reads for input (e.g. the python REPL).

That of course, would also be a "selection" that the Terminal couldn't know about - that would all be internal to the console itself. That "selection" would be entirely independent of the end terminal, so thinks like mark mode wouldn't operate on that selection, which would be wEiRd.

Alas, we actually can't really make changes like that to cmd.exe.

Maybe there's some way we could:

  • have terminal request "CookedReadV2" from the console, so that Terminal itself could opt in to new commandline handling, while conhost remains opted out
  • have conpty transmit "selection" state to the end terminal (and vice versa)

</notes from trying to fall asleep>

I think probably the better solution here is something built on top of shell integration.

@zadjii-msft commented on GitHub (Jun 6, 2023): FWIW the Ctrl+A handling in PowerShell is done by PsReadline (a powershell module), not the terminal / console itself. The "selection" created by Ctrl+A in pwsh is entirely something that pwsh itself is maintaining, not something more fundamental. Command Prompt doesn't use psreadline (obviously). It relies on the "cooked read" functionality of the console APIs themselves. Theoretically, if we _did_ want to fix this for cmd.exe, the place to do so would be in the cooked read handler in the console. That would add this for both cmd.exe and any other console apps that use cooked reads for input (e.g. the python REPL). That of course, would also be a "selection" that the Terminal couldn't know about - that would all be internal to the console itself. That "selection" would be entirely independent of the end terminal, so thinks like mark mode wouldn't operate on that selection, which would be wEiRd. Alas, we actually [can't really make changes like that to cmd.exe](https://github.com/microsoft/terminal/blob/main/doc/Niksa.md#why-do-we-avoid-changing-cmdexe). Maybe there's some way we could: * have terminal request "CookedReadV2" from the console, so that Terminal itself could opt in to new commandline handling, while conhost remains opted out * have conpty transmit "selection" state to the end terminal (and vice versa) \</notes from trying to fall asleep> ---- I think probably the better solution here is something built on top of [shell integration](https://github.com/MicrosoftDocs/terminal/blob/main/TerminalDocs/tutorials/shell-integration.md).
claunia commented 2026-01-31 07:01:15 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 6, 2023):

the place to do so would be in the cooked read handler in the console.

I do believe that our architectural "purity" is holding us back a little bit here.

Why doesn't ConPTY's input state machine produce conhost input1 ? If it did, we would get all of the cooked read line editing stuff for free. Sure, selection would turn out strange but like... it already does in PowerShell.

ConPTY is 50% an interface to a console application and 50% an interface to conhost2 . Why have we decided that ^A goes through to the application but F7 gets caught up by COOKED_READ? It's roughly the same thing!

  1. right now it produces input to be formatted for the input stream ↩︎

  2. F7 ↩︎

@DHowett commented on GitHub (Jun 6, 2023): > the place to do so would be in the cooked read handler in the console. I do believe that our architectural "purity" is holding us back a little bit here. Why doesn't ConPTY's input state machine produce _conhost_ input[^1]? If it did, we would get all of the cooked read line editing stuff for _free_. Sure, selection would turn out strange but like... it already does in PowerShell. ConPTY is 50% an interface to a console application and 50% an interface to conhost[^2]. Why have we decided that `^A` goes through to the application but `F7` gets caught up by `COOKED_READ`? It's roughly the same thing! [^1]: right now it produces input to be formatted for the input stream [^2]: `F7`
claunia commented 2026-01-31 07:01:15 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Jun 7, 2023):

Tagged up, but leaving "Needs-Triage" on it so we can further discuss as a team.

@carlos-zamora commented on GitHub (Jun 7, 2023): Tagged up, but leaving "Needs-Triage" on it so we can further discuss as a team.
claunia commented 2026-01-31 07:01:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 12, 2023):

tldr:

ctrl+a over conpty to a client doing a cooked read should do the same thing as conhost. Great.

@zadjii-msft commented on GitHub (Jul 12, 2023): tldr: ctrl+a over conpty to a client doing a cooked read should do the same thing as conhost. Great.
claunia commented 2026-01-31 07:01:16 +00:00
Author
Owner
Copy Link

@carehart commented on GitHub (Jul 12, 2023):

@zadjii-msft , is your tldr there simply summarizing my original request (and replies since)? Or are you somehow reflecting work that's now been done on the team regarding the request? (The prior comment from @carlos-zamora was that it would indeed be triaged and "discussed as a team", a few weeks ago.) I do see you also removed the "needs triage" tag. If this means perhaps the issue has moved up in priority, great. :-)

I appreciate that may not mean "solved any time soon". Just clarifying that I'm not a regular here, so not familiar with the process that requests go through. Thanks.

@carehart commented on GitHub (Jul 12, 2023): @zadjii-msft , is your tldr there simply summarizing my original request (and replies since)? Or are you somehow reflecting work that's now been done on the team regarding the request? (The prior comment from @carlos-zamora was that it would indeed be triaged and "discussed as a team", a few weeks ago.) I do see you also removed the "needs triage" tag. If this means perhaps the issue has moved up in priority, great. :-) I appreciate that may not mean "solved any time soon". Just clarifying that I'm not a regular here, so not familiar with the process that requests go through. Thanks.
claunia commented 2026-01-31 07:01:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 13, 2023):

Ah, it's more a reflection on the root cause here. I know it sounds like I just said the same thing as you, but I'm more ID'ing exactly where in the codebase to go fix this. (It's probably one of https://github.com/microsoft/terminal/blob/main/src/terminal/adapter/InteractDispatch.cpp or https://github.com/microsoft/terminal/blob/main/src/terminal/parser/InputStateMachineEngine.cpp).

Wait though we were maybe a bit hasty. We may have just yanked triage quick cause it was the last one on the queue at 5pm.

There's still the open question - when the user does press Ctrl+A, and conpty "selects" the entire input - how would we convey that info to a terminal to render that? I don't think there's an existing VT sequence for a client app to communicate "this region is selected".

It might be easy enough to accept the ^A and have conpty internally select the text, but without rendering it back to the terminal, you're in a bit of a magic state.

@zadjii-msft commented on GitHub (Jul 13, 2023): Ah, it's more a reflection on the root cause here. I know it sounds like I just said the same thing as you, but I'm more ID'ing exactly where in the codebase to go fix this. (It's probably one of https://github.com/microsoft/terminal/blob/main/src/terminal/adapter/InteractDispatch.cpp or https://github.com/microsoft/terminal/blob/main/src/terminal/parser/InputStateMachineEngine.cpp). ---- Wait though we were maybe a _bit_ hasty. We may have just yanked triage quick cause it was the last one on the queue at 5pm. There's still the open question - when the user does press Ctrl+A, and conpty "selects" the entire input - how would we convey that info to a terminal to render that? I don't think there's an existing VT sequence for a client app to communicate "this region is selected". It might be easy enough to accept the ^A and have conpty internally select the text, but without rendering it back to the terminal, you're in a bit of a magic state.
claunia commented 2026-01-31 07:01:17 +00:00
Author
Owner
Copy Link

@carehart commented on GitHub (Jul 13, 2023):

Ah, OK. Thanks. I'll leave you titans to rumble. :-)

@carehart commented on GitHub (Jul 13, 2023): Ah, OK. Thanks. I'll leave you titans to rumble. :-)
claunia commented 2026-01-31 07:01:17 +00:00
Author
Owner
Copy Link

@piecevcake commented on GitHub (Oct 14, 2024):

Ah, it's more a reflection on the root cause here. I know it sounds like I just said the same thing as you, but I'm more ID'ing exactly where in the codebase to go fix this. (It's probably one of https://github.com/microsoft/terminal/blob/main/src/terminal/adapter/InteractDispatch.cpp or https://github.com/microsoft/terminal/blob/main/src/terminal/parser/InputStateMachineEngine.cpp).

Hey if it's too hard, why not just add an option to copy/log the entire cmd window contents to a file either as they appear or on closing the window. We put people on the moon, you know.

When I pressed Ctrl_A the cmd administrator window closed and I lost the entire record of what I had changed, executing a Take Ownership app.

@piecevcake commented on GitHub (Oct 14, 2024): > Ah, it's more a reflection on the root cause here. I know it sounds like I just said the same thing as you, but I'm more ID'ing exactly where in the codebase to go fix this. (It's probably one of https://github.com/microsoft/terminal/blob/main/src/terminal/adapter/InteractDispatch.cpp or https://github.com/microsoft/terminal/blob/main/src/terminal/parser/InputStateMachineEngine.cpp). > Hey if it's too hard, why not just add an option to copy/log the entire cmd window contents to a file either as they appear or on closing the window. We put people on the moon, you know. When I pressed Ctrl_A the cmd administrator window closed and I lost the entire record of what I had changed, executing a Take Ownership app.
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-Interaction Issue-Feature Product-Conpty
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#20027
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?