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

[Question] Pass command text in but do not execute #14215

New Issue
Closed
opened 2026-01-31 04:04:06 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 04:04:06 +00:00
Owner
Copy Link

Originally created by @shaggygi on GitHub (Jun 12, 2021).

Description of the new feature/enhancement

This is more of a question, but could lead to feature if not available. I'm wanting to know if there is a way to pass a command/text into WT without actually executing the command? For example, I have a partial command I want to load/display in WT and have ready to type in the remaining part of the command.

Proposed technical implementation details (optional)

Originally created by @shaggygi on GitHub (Jun 12, 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 This is more of a question, but could lead to feature if not available. I'm wanting to know if there is a way to pass a command/text into WT without actually executing the command? For example, I have a partial command I want to load/display in WT and have ready to type in the remaining part of the command. <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> # Proposed technical implementation details (optional) <!-- A clear and concise description of what you want to happen. -->
claunia commented 2026-01-31 04:04:08 +00:00
Author
Owner
Copy Link

@orcmid commented on GitHub (Jun 12, 2021):

I think there is a misunderstanding of where the echo of stdin to the terminal display happens when you are keying at the console (and it could be my misunderstanding).

I think the ordinary way this is handled is by a new-line entry that is not taken as an end-of-line or "send." Ctrl-Enter, typically. I don't know what stdin delivers, if anything. There is an impact on the input history also, and recalling a "line" in the history, and scrolling back through it should work properly. If the app is asking for a line, that should includes everything to the final Enter whether originally entered or re-entered (pasted)) from the history (without the final, emphatic Enter, so the entry can be confirmed/edited first).

Using cmd.exe in the default console arrangement (without WT) as an example, it appears that there is an entry editor between the app (some shell or other process) and the keyboard and the display of the entry. In this case, and this presumably (need) not be handled directly by the app. I don't know enough about the innards to know whether cmd.exe (for example) provides this or has a way to ask for it. I trust that the abstractions can be layered and stitched properly with the advent of WT.

There are also accessibility considerations around how all this operates and I have no idea how that is addressed, only that it must be. Impacts by windows resizing should not matter (that is, such liine-breaking/-stitcching is probably not visible to the console app at all.

Finally, if the console app is a command-line shell, and a console app is launched, the ordinary arrangements seems to be that no line editor (or history) intervenes for that wiring of stdin and such, even if tied to the same terminal. That seems appropriate. An ordinary console app should not be able to piggy-back on all that and might even establish a different "display."

This is rather far from the feature request. It does inspire consideration of the layers of abstraction and how they are wired up. That's been on my mind in attempting to comprehend the levels of abstraction and separation of concerns that seem to arise in cosideration of WT features, even for me as an interested observer.

PS: A non-breaking newline is also desirable in the creation of script (e.g., bat) files. ;)

PPS: [2021-06-13T17:17Z] Then there are redirections and pipes to consider. And it is all supposed to work [;<).

@orcmid commented on GitHub (Jun 12, 2021): I think there is a misunderstanding of where the echo of stdin to the terminal display happens when you are keying at the console (and it could be my misunderstanding). I think the ordinary way this is handled is by a new-line entry that is not taken as an end-of-line or "send." Ctrl-Enter, typically. I don't know what `stdin` delivers, if anything. There is an impact on the input history also, and recalling a "line" in the history, and scrolling back through it should work properly. If the app is asking for a line, that should includes everything to the final Enter whether originally entered or re-entered (pasted)) from the history (without the final, emphatic Enter, so the entry can be confirmed/edited first). Using `cmd.exe` in the default console arrangement (without WT) as an example, it appears that there is an entry editor between the app (some shell or other process) and the keyboard and the display of the entry. In this case, and this presumably (need) not be handled directly by the app. I don't know enough about the innards to know whether cmd.exe (for example) provides this or has a way to ask for it. I trust that the abstractions can be layered and stitched properly with the advent of WT. There are also accessibility considerations around how all this operates and I have no idea how that is addressed, only that it must be. Impacts by windows resizing should not matter (that is, such liine-breaking/-stitcching is probably not visible to the console app at all. Finally, if the console app is a command-line shell, and a console app is launched, the ordinary arrangements seems to be that no line editor (or history) intervenes for that wiring of `stdin` and such, even if tied to the same terminal. That seems appropriate. An ordinary console app should not be able to piggy-back on all that and might even establish a different "display." This is rather far from the feature request. It does inspire consideration of the layers of abstraction and how they are wired up. That's been on my mind in attempting to comprehend the levels of abstraction and separation of concerns that seem to arise in cosideration of WT features, even for me as an interested observer. PS: A non-breaking newline is also desirable in the creation of script (e.g., `bat`) files. ;) PPS: [2021-06-13T17:17Z] Then there are redirections and pipes to consider. And it is all supposed to work [;<).
claunia commented 2026-01-31 04:04:08 +00:00
Author
Owner
Copy Link

@skyline75489 commented on GitHub (Jun 15, 2021):

For shells that support bracketed paste mode (for example bash, zsh, ipython & etc), this is possible and usually work out of the box.

Unfortunely both cmd.exe & PowerShell do not support bracketed paste mode at the moment.

@skyline75489 commented on GitHub (Jun 15, 2021): For shells that support [bracketed paste mode](https://github.com/microsoft/terminal/issues/395) (for example bash, zsh, ipython & etc), this is possible and usually work out of the box. Unfortunely both cmd.exe & PowerShell do not support bracketed paste mode at the moment.
claunia commented 2026-01-31 04:04:08 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 15, 2021):

@shaggygi In which way specifically do you want to pass commands? As a shortcut action?
Windows Terminal already supports pasting in text. If you Ctrl+V a single line command it'll work as you wanted.
Alternatively you can also use the sendInput action for shortcuts.

As mentioned by @skyline75489 cmd.exe and PowerShell don't support bracketed paste mode, which makes it (basically) impossible to enter multiline commands programmatically without executing them immediately.

@lhecker commented on GitHub (Jun 15, 2021): @shaggygi In which way specifically do you want to pass commands? As a shortcut action? Windows Terminal already supports pasting in text. If you Ctrl+V a single line command it'll work as you wanted. Alternatively you can also use the [`sendInput` action](https://docs.microsoft.com/en-us/windows/terminal/customize-settings/actions#send-input) for shortcuts. As mentioned by @skyline75489 cmd.exe and PowerShell don't support bracketed paste mode, which makes it (basically) impossible to enter multiline commands programmatically without executing them immediately.
claunia commented 2026-01-31 04:04:08 +00:00
Author
Owner
Copy Link

@shaggygi commented on GitHub (Jun 15, 2021):

@shaggygi In which way specifically do you want to pass commands? As a shortcut action?

I basically have a utility that generates some initial text for a command based on selections from the utility. I would like to open WT (via the utility) and add that text to the prompt (using CMD as default). I can then add the remaining text before submitting command. For example...

(within WT showing path to EXE with initial arguments.)
C:\Temp> "MyExe.exe" -arg1 "data" -arg2 "more data" -arg3

Then I would add the remaining and press Enter.
C:\Temp> "MyExe.exe" -arg1 "data" -arg2 "more data" -arg3 "Remaining Data"

@shaggygi commented on GitHub (Jun 15, 2021): > @shaggygi In which way specifically do you want to pass commands? As a shortcut action? I basically have a utility that generates some initial text for a command based on selections from the utility. I would like to open WT (via the utility) and add that text to the prompt (using CMD as default). I can then add the remaining text before submitting command. For example... (within WT showing path to EXE with initial arguments.) C:\Temp> "MyExe.exe" -arg1 "data" -arg2 "more data" -arg3 Then I would add the remaining and press Enter. C:\Temp> "MyExe.exe" -arg1 "data" -arg2 "more data" -arg3 "Remaining Data"
claunia commented 2026-01-31 04:04:09 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 15, 2021):

I'm assuming your utility is a separate process, right?

On one hand we could implement (PRs welcome! 😄): https://github.com/microsoft/terminal/issues/9368
But if you want to send input to an existing window you'd have to know the window name.
If you don't, you can use one of the many different approaches to send text input to another process on Windows. There's the clipboard API, EM_REPLACESEL, SendMessage, etc.
But I'm not sure if they're best suited for that task. I believe you should probably use "UI Automation" (UIA) for this purpose. This would in fact likely be required if you want to send input to an unfocused WT window, as WT might not have text focus. UIA is a very powerful tool. Try running accevent.exe or inspect.exe in your Windows SDK (if you have it installed), to get an idea.
In any case the solution for your problem depends heavily on several factors, most importantly which window should receive the input (always the focused window and pane?), but also whether you want to send VT sequences for instance.

@lhecker commented on GitHub (Jun 15, 2021): I'm assuming your utility is a separate process, right? On one hand we could implement (PRs welcome! 😄): https://github.com/microsoft/terminal/issues/9368 But if you want to send input to an existing window you'd have to know the window name. If you don't, you can use one of the many different approaches to send text input to another process on Windows. There's the clipboard API, `EM_REPLACESEL`, `SendMessage`, etc. But I'm not sure if they're best suited for that task. I believe you should probably use "UI Automation" (UIA) for this purpose. This would in fact likely be required if you want to send input to an unfocused WT window, as WT might not have text focus. UIA is a very powerful tool. Try running `accevent.exe` or `inspect.exe` in your Windows SDK (if you have it installed), to get an idea. In any case the solution for your problem depends heavily on several factors, most importantly which window should receive the input (always the focused window and pane?), but also whether you want to send VT sequences for instance.
claunia commented 2026-01-31 04:04:09 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 22, 2022):

Hey sorry for letting this one sit for so long! This does sound a lot like /dup #9368, we may as well track this request there.

@zadjii-msft commented on GitHub (Aug 22, 2022): Hey sorry for letting this one sit for so long! This does sound a lot like /dup #9368, we may as well track this request there.
claunia commented 2026-01-31 04:04:09 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 22, 2022):

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 (Aug 22, 2022): 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.
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-TerminalControl Issue-Question Needs-Tag-Fix Product-Terminal Resolution-Duplicate
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#14215
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?