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

WSL: Pasting text from a clipboard manager doesn't insert text at the console's cursor #476

New Issue
Open
opened 2026-01-30 21:53:14 +00:00 by claunia · 20 comments
claunia commented 2026-01-30 21:53:14 +00:00
Owner
Copy Link

Originally created by @nickjj on GitHub (Dec 9, 2018).

Microsoft Windows [Version 10.0.17763.134]

I'm using Ubuntu WSL and the default ubuntu.exe terminal. It's been configured so that CTRL+Shift+C/V allow for copy / pasting, which by itself is working.

However, I use Ditto which is an open source clipboard manager which allows you to write to and access multiple clipboard items. It can be found at https://ditto-cp.sourceforge.io/.

Expected outcome

  • Store multiple items in the Ditto clipboard by using the clipboard naturally.
  • Trigger the Ditto menu to pick an item using Ditto's registered key binding of CTRL + ALT + V.
  • Select the desired clipboard item from Ditto's menu.
  • See the clipboard item output at my cursor inside of the Ubuntu terminal so I can press enter to execute the command (or do whatever I want with the text that was inserted).

Actual outcome

  • Store multiple items in the Ditto clipboard by using the clipboard naturally.
  • Trigger the Ditto menu to pick an item using Ditto's registered key binding of CTRL + ALT + V.
  • Select the desired clipboard item from Ditto's menu.
  • See nothing in the Ubuntu terminal because the item gets absorbed by ubuntu.exe, and occasionally see ^V instead of the desired text depending on how I select the item (mouse click or pressing Enter).

I've tried other terminals like ConEmu and Hyper, and in those cases Ditto works. Ditto also works just fine with every other application (browser, IRC client, code editor, etc.). It's only failing with ubuntu.exe and related terminals.

Originally created by @nickjj on GitHub (Dec 9, 2018). Microsoft Windows [Version 10.0.17763.134] --- I'm using Ubuntu WSL and the default `ubuntu.exe` terminal. It's been configured so that `CTRL+Shift+C/V` allow for copy / pasting, which by itself is working. However, I use Ditto which is an open source clipboard manager which allows you to write to and access multiple clipboard items. It can be found at https://ditto-cp.sourceforge.io/. #### Expected outcome - Store multiple items in the Ditto clipboard by using the clipboard naturally. - Trigger the Ditto menu to pick an item using Ditto's registered key binding of `CTRL + ALT + V`. - Select the desired clipboard item from Ditto's menu. - See the clipboard item output at my cursor inside of the Ubuntu terminal so I can press enter to execute the command (or do whatever I want with the text that was inserted). #### Actual outcome - Store multiple items in the Ditto clipboard by using the clipboard naturally. - Trigger the Ditto menu to pick an item using Ditto's registered key binding of `CTRL + ALT + V`. - Select the desired clipboard item from Ditto's menu. - See nothing in the Ubuntu terminal because the item gets absorbed by `ubuntu.exe`, and occasionally see `^V` instead of the desired text depending on how I select the item (mouse click or pressing Enter). I've tried other terminals like ConEmu and Hyper, and in those cases Ditto works. Ditto also works just fine with every other application (browser, IRC client, code editor, etc.). It's only failing with `ubuntu.exe` and related terminals.
claunia added the Product-ConhostIssue-QuestionArea-Interaction labels 2026-01-30 21:53:14 +00:00
claunia commented 2026-01-30 21:53:15 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 10, 2018):

It sounds to me like this is a Ditto problem.

When you see ^V in conhost (the terminal application for all commandline applications on Windows) after selecting an item from the Ditto menu, that's likely because Ditto is sending a series of Window Messages to the console window, messages which are effectively saying "ctrl-V was pressed".

However, Ctrl+V isn't the keybinding that's mapped to paste in wsl, Ctrl+Shift+V is. Is there some way that Ditto could send us a window message other than Ctrl+V? Is there not a WM_PASTE window message or something? We can't just respond to all Ctrl+V events on the client application's behalf due to legacy reasons.

@zadjii-msft commented on GitHub (Dec 10, 2018): It sounds to me like this is a Ditto problem. When you see `^V` in conhost (the terminal application for all commandline applications on Windows) after selecting an item from the Ditto menu, that's likely because Ditto is sending a series of Window Messages to the console window, messages which are effectively saying "ctrl-V was pressed". However, Ctrl+V isn't the keybinding that's mapped to paste in wsl, Ctrl+Shift+V is. Is there some way that Ditto could send us a window message other than Ctrl+V? Is there not a WM_PASTE window message or something? We can't just respond to all Ctrl+V events on the client application's behalf due to legacy reasons.
claunia commented 2026-01-30 21:53:15 +00:00
Author
Owner
Copy Link

@nickjj commented on GitHub (Dec 10, 2018):

When I click the Ditto item with the mouse I don't see the ^V character, instead I see no output at all. The ^V only happens if I press enter to select the item.

I had configured Hyper to use CTRL + Shift + V for pasting and Ditto still worked there when I clicked the Ditto item with the mouse, but the same exact situation with ubuntu.exe doesn't work. Other terminals and VSCode also work (even if I configure their paste to be something other than CTRL +V).

Ditto has a way to customize which copy window messages are supported, but not paste. Maybe it could be done at the source level but I'm not the developer, just an end user.

@nickjj commented on GitHub (Dec 10, 2018): When I click the Ditto item with the mouse I don't see the `^V` character, instead I see no output at all. The `^V` only happens if I press enter to select the item. I had configured Hyper to use CTRL + Shift + V for pasting and Ditto still worked there when I clicked the Ditto item with the mouse, but the same exact situation with `ubuntu.exe` doesn't work. Other terminals and VSCode also work (even if I configure their paste to be something other than CTRL +V). Ditto has a way to customize which copy window messages are supported, but not paste. Maybe it could be done at the source level but I'm not the developer, just an end user.
claunia commented 2026-01-30 21:53:16 +00:00
Author
Owner
Copy Link

@nickjj commented on GitHub (Dec 10, 2018):

It's also worth pointing out I tried another clipboard manager and for the ubuntu.exe terminal it has the same behavior as Ditto, where as it works with other terminals.

@nickjj commented on GitHub (Dec 10, 2018): It's also worth pointing out I tried another clipboard manager and for the `ubuntu.exe` terminal it has the same behavior as Ditto, where as it works with other terminals.
claunia commented 2026-01-30 21:53:16 +00:00
Author
Owner
Copy Link

@SamB commented on GitHub (May 4, 2019):

Well, https://docs.microsoft.com/en-us/windows/desktop/dataxchg/wm-paste only documents WM_PASTE as applying to "an edit control or combo box", and the latter apparently just passes it down to its edit control (if it has one) anyway. So, probably not the most helpful here...

@SamB commented on GitHub (May 4, 2019): Well, https://docs.microsoft.com/en-us/windows/desktop/dataxchg/wm-paste only documents `WM_PASTE` as applying to "an edit control or combo box", and the latter apparently just passes it down to its edit control (if it has one) anyway. So, probably not the most helpful here...
claunia commented 2026-01-30 21:53:17 +00:00
Author
Owner
Copy Link

@cmskzhan commented on GitHub (May 22, 2019):

I'm more used to the old shift+insert to paste. this doesn't seems to work either.

@cmskzhan commented on GitHub (May 22, 2019): I'm more used to the old shift+insert to paste. this doesn't seems to work either.
claunia commented 2026-01-30 21:53:17 +00:00
Author
Owner
Copy Link

@sabrogden commented on GitHub (Dec 11, 2019):

I see two options,

  1. Map ctrl-v to be paste in terminal

"keybindings": [
{
"command": "paste",
"keys": ["ctrl+v"]
},
{
"command": "copy",
"keys": ["ctrl+c"]
}
]

  1. Change Ditto to send CTRL + Shift + V to perform the paste, https://sourceforge.net/p/ditto-cp/wiki/Custom%20Key%20Strokes/

[HKEY_CURRENT_USER\Software\Ditto\PasteStrings]
"WindowsTerminal.exe"="+^{VKEY86}"

@sabrogden commented on GitHub (Dec 11, 2019): I see two options, 1. Map ctrl-v to be paste in terminal > "keybindings": [ { "command": "paste", "keys": ["ctrl+v"] }, { "command": "copy", "keys": ["ctrl+c"] } ] 2. Change Ditto to send CTRL + Shift + V to perform the paste, https://sourceforge.net/p/ditto-cp/wiki/Custom%20Key%20Strokes/ > [HKEY_CURRENT_USER\Software\Ditto\PasteStrings] "WindowsTerminal.exe"="+^{VKEY86}"
claunia commented 2026-01-30 21:53:18 +00:00
Author
Owner
Copy Link

@ctyjiuh commented on GitHub (Sep 20, 2020):

What about windows 10 natvie clipboard history, not Ditto? I mean win + v

@ctyjiuh commented on GitHub (Sep 20, 2020): What about windows 10 natvie clipboard history, not Ditto? I mean win + v
claunia commented 2026-01-30 21:53:18 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 21, 2020):

@ctyjiuh Windows 10 Clipboard History works the same way: by simulating Ctrl+V. 😦

@DHowett commented on GitHub (Sep 21, 2020): @ctyjiuh Windows 10 Clipboard History works the same way: by simulating <kbd>Ctrl+V</kbd>. 😦
claunia commented 2026-01-30 21:53:18 +00:00
Author
Owner
Copy Link

@ctyjiuh commented on GitHub (Sep 21, 2020):

@DHowett oh. Thank you. My problem was I binded alt+v for paste and ctrl+v simulation led to nothing 😅. BInding ctrl+v solved problem.

@ctyjiuh commented on GitHub (Sep 21, 2020): @DHowett oh. Thank you. My problem was I binded alt+v for paste and ctrl+v simulation led to nothing 😅. BInding ctrl+v solved problem.
claunia commented 2026-01-30 21:53:19 +00:00
Author
Owner
Copy Link

@rnbdc commented on GitHub (Apr 26, 2021):

My problem with binding ctrl-v to "paste" is that I need crtl-v sometimes. Is there a way to send crtl-v to inside the terminal if it's bound to a shortcut? That would solve the problem. For example, crtl-v="paste" and crtl-shift-v="send crtl-v to inside the terminal".

@rnbdc commented on GitHub (Apr 26, 2021): My problem with binding ctrl-v to "paste" is that I need crtl-v sometimes. Is there a way to send crtl-v to inside the terminal if it's bound to a shortcut? That would solve the problem. For example, crtl-v="paste" and crtl-shift-v="send crtl-v to inside the terminal".
claunia commented 2026-01-30 21:53:19 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Apr 26, 2021):

@rnbdc sendInput configured as { "action": "sendInput", "input": "\u0016" } should match what unbound Ctrl+V sends, at least from the viewpoint of WSL. I'm not sure how that will populate the INPUT_RECORD from ReadConsoleInput, though.

@KalleOlaviNiemitalo commented on GitHub (Apr 26, 2021): @rnbdc [sendInput](https://docs.microsoft.com/en-us/windows/terminal/customize-settings/actions#send-input) configured as `{ "action": "sendInput", "input": "\u0016" }` should match what unbound Ctrl+V sends, at least from the viewpoint of WSL. I'm not sure how that will populate the INPUT_RECORD from ReadConsoleInput, though.
claunia commented 2026-01-30 21:53:19 +00:00
Author
Owner
Copy Link

@rnbdc commented on GitHub (Apr 27, 2021):

Indeed adding the following line did it:

{ "command": { "action": "sendInput", "input": "\u0016" }, "keys": "alt+shift+v" }

Now I can send ctrl-v on Windows Terminal, problem solved!

@rnbdc commented on GitHub (Apr 27, 2021): Indeed adding the following line did it: { "command": { "action": "sendInput", "input": "\u0016" }, "keys": "alt+shift+v" } Now I can send ctrl-v on Windows Terminal, problem solved!
claunia commented 2026-01-30 21:53:19 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Apr 27, 2021):

Thanks! We should add this tip to our documentation. :)

@DHowett commented on GitHub (Apr 27, 2021): Thanks! We should add this tip to our documentation. :)
claunia commented 2026-01-30 21:53:19 +00:00
Author
Owner
Copy Link

@rnbdc commented on GitHub (Apr 27, 2021):

Let me add that crtl-c already works because you guys did the smart trick of only using it for "copy" when some text is selected, and otherwise you just send it inside. But for crtl-v this is not possible, obviously.

@rnbdc commented on GitHub (Apr 27, 2021): Let me add that crtl-c already works because you guys did the smart trick of only using it for "copy" when some text is selected, and otherwise you just send it inside. But for crtl-v this is not possible, obviously.
claunia commented 2026-01-30 21:53:19 +00:00
Author
Owner
Copy Link

@sarim commented on GitHub (Oct 8, 2021):

Is there any way to check who is sending the keypress events? Like if it can be detected that Windows Clipboard History (which I guess explorer.exe ? or some svchost?) is sending Ctrl+V then invoke paste action instead of sending ctrl+v keystrokes to terminal. Could be a generic sender based action invoking configuration.

{
    "command": "paste",
    "keys": "ctrl+v",
    "senderProcess": "explorer.exe"
}
@sarim commented on GitHub (Oct 8, 2021): Is there any way to check who is sending the keypress events? Like if it can be detected that Windows Clipboard History (which I guess explorer.exe ? or some svchost?) is sending Ctrl+V then invoke paste action instead of sending ctrl+v keystrokes to terminal. Could be a generic sender based action invoking configuration. ```json { "command": "paste", "keys": "ctrl+v", "senderProcess": "explorer.exe" } ```
claunia commented 2026-01-30 21:53:20 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Oct 8, 2021):

Spy++ on Windows 10 build 19043.1237 shows the synthetic keyboards events as:

  • P WM_KEYDOWN nVirtyKey:VK_CONTROL cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 wParam:00000011 lParam:00000001
  • P WM_KEYDOWN nVirtKey:'V' cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 wParam:00000056 lParam:00000001
  • P WM_KEYUP nVirtKey:'V' cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:1 fUp:1 wParam:00000056 lParam:C0000001
  • P WM_KEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:1 fUp:1 wParam:00000011 lParam:C0000001

whereas an actual Ctrl+V keypress is:

  • P WM_KEYDOWN nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:0 fRepeat:0 fUp:0 wParam:00000011 lParam:001D0001
  • P WM_KEYDOWN nVirtKey:'V' cRepeat:1 ScanCode:2F fExtended:0 fAltDown:0 fRepeat:0 fUp:0 wParam:00000056 lParam:002F0001
  • P WM_KEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:0 fRepeat:1 fUp:1 wParam:00000011 lParam:C01D0001
  • P WM_KEYUP nVirtKey:'V' cRepeat:1 ScanCode:2F fExtended:0 fAltDown:0 fRepeat:1 fUp:1 wParam:00000056 lParam:C01F0001

So, Windows Terminal could perhaps recognize the synthetic keyboard events from ScanCode:00. I suspect that accessibility or macro software might likewise synthesize events with ScanCode:00, but if this were an opt-in feature in Windows Terminal, then that could be OK.

{
    "command": "paste",
    "keys": "ctrl+v",
    "syntheticKeysOnly": true
}
@KalleOlaviNiemitalo commented on GitHub (Oct 8, 2021): Spy++ on Windows 10 build 19043.1237 shows the synthetic keyboards events as: * P WM_KEYDOWN nVirtyKey:VK_CONTROL cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 wParam:00000011 lParam:00000001 * P WM_KEYDOWN nVirtKey:'V' cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 wParam:00000056 lParam:00000001 * P WM_KEYUP nVirtKey:'V' cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:1 fUp:1 wParam:00000056 lParam:C0000001 * P WM_KEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:1 fUp:1 wParam:00000011 lParam:C0000001 whereas an actual Ctrl+V keypress is: * P WM_KEYDOWN nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:0 fRepeat:0 fUp:0 wParam:00000011 lParam:001D0001 * P WM_KEYDOWN nVirtKey:'V' cRepeat:1 ScanCode:2F fExtended:0 fAltDown:0 fRepeat:0 fUp:0 wParam:00000056 lParam:002F0001 * P WM_KEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:0 fRepeat:1 fUp:1 wParam:00000011 lParam:C01D0001 * P WM_KEYUP nVirtKey:'V' cRepeat:1 ScanCode:2F fExtended:0 fAltDown:0 fRepeat:1 fUp:1 wParam:00000056 lParam:C01F0001 So, Windows Terminal could perhaps recognize the synthetic keyboard events from ScanCode:00. I suspect that accessibility or macro software might likewise synthesize events with ScanCode:00, but if this were an opt-in feature in Windows Terminal, then that could be OK. ```JSON { "command": "paste", "keys": "ctrl+v", "syntheticKeysOnly": true } ```
claunia commented 2026-01-30 21:53:20 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Oct 8, 2021):

If the clipboard history feature uses SendInput, it could potentially store an identifier in KEYBDINPUT::dwExtraInfo, and Windows Terminal could then recognize that. Spy++ unfortunately does not show the extra info.

@KalleOlaviNiemitalo commented on GitHub (Oct 8, 2021): If the clipboard history feature uses [SendInput](https://docs.microsoft.com/windows/win32/api/winuser/nf-winuser-sendinput), it could potentially store an identifier in [KEYBDINPUT::dwExtraInfo](https://docs.microsoft.com/windows/win32/api/winuser/ns-winuser-keybdinput), and Windows Terminal could then recognize that. Spy++ unfortunately does not show the extra info.
claunia commented 2026-01-30 21:53:20 +00:00
Author
Owner
Copy Link

@sarim commented on GitHub (Oct 8, 2021):

@KalleOlaviNiemitalo Inputs from remote desktop application are also synthetic right? Like VNC, Anydesk, Teamviewer, Windows Remote Desktop etc...
So checking only if keypress is synthetic or not wouldn't be enough. Can you check what event is passed when any remote desktop app sends the input?

@sarim commented on GitHub (Oct 8, 2021): @KalleOlaviNiemitalo Inputs from remote desktop application are also synthetic right? Like VNC, Anydesk, Teamviewer, Windows Remote Desktop etc... So checking only if keypress is synthetic or not wouldn't be enough. Can you check what event is passed when any remote desktop app sends the input?
claunia commented 2026-01-30 21:53:20 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Oct 8, 2021):

Didn't test yet, but TS_KEYBOARD_EVENT in [MS-RDPBCGR] specifically contains the scancode. TS_FP_KEYBOARD_EVENT likewise.

@KalleOlaviNiemitalo commented on GitHub (Oct 8, 2021): Didn't test yet, but [TS_KEYBOARD_EVENT in [MS-RDPBCGR]](https://docs.microsoft.com/openspecs/windows_protocols/ms-rdpbcgr/7acaec9f-c8a6-4ee9-87d6-d9b89cf56489) specifically contains the scancode. [TS_FP_KEYBOARD_EVENT](https://docs.microsoft.com/openspecs/windows_protocols/ms-rdpbcgr/089d362b-31eb-4a1a-b6fa-92fe61bb5dbf) likewise.
claunia commented 2026-01-30 21:53:20 +00:00
Author
Owner
Copy Link

@NewtonChutney commented on GitHub (Jan 5, 2024):

Was ctrl+v for the paste action by default in later releases?
I currently seem to have that set

@NewtonChutney commented on GitHub (Jan 5, 2024): Was `ctrl+v` for the paste action by default in later releases? I currently seem to have that set
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-Question Product-Conhost
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#476
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?