-
Notifications
You must be signed in to change notification settings - Fork 806
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ctrl+V not working #2944
Comments
@DarthSpock |
I have the same issue. I see snide phrases like "dead giveaway" that are not explaining the issue. Please would someone explain how to fix this or how to file this in a way the elicits more than snarky remarks. Thank you. |
@edpell Next Feature Update will bring CTRL+SHIFT+C and CTRL+SHIFT+V support. |
Why Ctrl+Shift+V? Why not make it work the as in the command prompt?? |
@thany Because Unix terminal has always been like this. CTRL+C and CTRL+V have already a reason to exist different from copy/paste. |
Ctrl+V doesn't do anything in WLS. Besides, consistency is more important than legacy. Also I didn't say anything about Ctrl+C. I know that one means "break", just and in cmd. Selecting with mouse and hitting Enter is a perfectly sane way to copy text. Already works btw. It's the same between cmd and wls, which is a good thing to have. |
That's even weirder. At least the menu is on the right track. Anyway,
To aid users who desperately want Ctrl+Shift+V to paste, let's implement both Ctrl+Shift+V AND Ctrl+V. |
@thany @kthy This issue is closed because it's a Console issue not a WSL actionable and one that has already been resolved: https://blogs.msdn.microsoft.com/commandline/2018/04/13/copy-and-paste-arrives-for-linuxwsl-consoles/ For future Console requests/issues, use the UserVoice linked above and https://github.com/Microsoft/Console/issues |
That's nice. So displaying Ctrl-V as shortcut for paste is a feature, even though that's not the shortcut that was implemented? #JustMicrosoftThings |
@DarthSpock Ctrl+Shift+V also doesn't work. |
Since it hasn't been referenced yet (apologies for not doing so), here's the reference in the proper Console tracker for this issue: microsoft/terminal#264 which provides guidance from a Console dev. |
No difference. Ctrl+V does paste in command prompt, but does not paste in WSL. All on the same pc, same network, same user, same day, same moon phase. |
Works for me here with "Use Ctrl+Shift+C/V as Copy/Paste" set. This is on 18267. The behavior of Ctrl-V is not on planet actionable. WSL (and the Real Linux™ kernel) has never heard of a 'paste', triggered by Ctrl-V or otherwise. And this issue is closed. |
Which is why we can assign it to Paste. |
The Linux kernel has never heard of "to Paste" either. [Fun but unrelated trivia: "Paste", meanwhile, has nothing to do with anything the kernel cares about. WSL hasn't the faintest idea what is in your Windows paste buffer. Or in the paste buffer of someone loitering in a Starbucks halfway around the world using a Macbook Air connected to Ubuntu on WSL via |
@therealkenc You are explaining exactly why Ctrl+V could be used for pasting. Of course the kernel doesn't know about it. That's why it will work! Paste is essentially just inserting the characters in the clipboard, into WSL as if they were typed in. That's how it works when right-clicking, and that's how it should work when Ctrl+V'ing. |
Paste does not insert anything into WSL; essentially, or otherwise. |
As @thany mentioned
Strangely, Ctrl+V does paste inside the VS Code integrated terminal (setup to use WSL).
This behavior suggests it's the command prompt window and how it processes Ctrl key commands once you've invoked the WSL kernel. Hope this helps! |
Not strange.
Correct. The paste operation in Windows Console with WSL is
The WSL kernel has nothing to do with it, and does not know nor does not care what |
Maybe you're misunderstand my point there. Clearly it does something when rightclicking the terminal. It inserts the contents of the clipboard. It does, really. It definitely inserts something. Whether it does that by "typing" I don't know, but afaik this is how most terminals work - including Windows' command prompt & powershell, macOS' terminal, Ubuntu's terminal, etc. They somehow inject "typing", which can easily be proved by pasting characters that control a program in some way. |
No I understood you fine.
Pronoun. You mean Windows Console. Not WSL. Which is the tracker you're in right now.
Mostly Mike I think.
..into the Windows Console. WSL doesn't know about typing either. No keyboard driver. Some loose ends from earlier posts since I'm here...
Not weird.
For example tools like GNU
Pretty much everyone who has used
No, it (the Windows Console) sends a
In any event, it appears 1809 hasn't hit the street yet. Ctrl+Shift+V should start pasting into the Windows Console with WSL for you when it does. Bonne chance. |
Please stop ripping my sentences apart and putting them out of context. Of course Mike isn't inserting anything into my console. Let me repeat myself: Ctrl+V does work in Command Prompt. You claim WSL runs on the same console. Fine. But in WSL paste doesn't work, so WSL is doing something or whatever that breaks it. So the issue is somehwere around WSL. Not in the windows console, not in command prompt, not in the linux kernel, but that magical layer in between all of them: WSL. The bug is in WSL, because that's the only place where paste doesn't work. Now please stop arguing about what WSL is or isn't, and accept that paste just doesn't bloody work on WSL only. Please.
I meant Ctrl+V.
Okay. So instead of sending |
Paste works in WSL. It just has a different keyboard shortcut. This is because of Reasons™. |
I understood you. In your context you meant Mike when you said 'they [the coders] inject typing [by way of their implementation]', and I had already given you a hard time about pronouns. Plus Mike and the rest of the Console team did an amazing job so I wanted to give credit where credit was due.
Ctrl+V does work in WSL (strictly speaking,
The layer in between the Windows Console and the WSL kernel is pretty magical, I'll give you that. But ConPTY just passes on the
You perceive an argument where none exists. This WSL tracker has been closed since February.
Yes, it (the Windows Console) could do that. Wouldn't be rocket science. They (by which I mean Mike) won't, of course, to quoth "ensure that we [Rich means the Console team] don't break any existing behaviors". In fact it was pretty tricky (maybe not rocket science but definitely computer science) for the Console team to change their paste behavior to Ctrl+Shift+V without breaking existing Powershell behavior or break existing Linux/Unix behavior. Or prevent Ctrl+V from being incongruous with Ctrl+C. Quite a feat really. Which is probably why it took two years. |
Either way, I would like Ctrl+V to execute paste. For me, having Ctrl+Shift+V is wasted effort, because my muscle memory is hard-wired to Ctrl+V and has been for several decades. So a checkbox like "Ctrl+V means paste but it breaks that one obscure terminal program that uses 0x16 control codes to do something uninteresting" with a big fat tick, would do it for me :) |
cc @bitcrazed for Console guidance |
Are there any updates to this issue? Seems like the misleading menu option for "Paste Ctrl-V" works but the actual hotkey does not. It worked for me for a few moments, but a new shell brought it back to the broken state. I was not able to reproduce the working state. It's also worth noting that while the Windows 10 Build 18362 |
@victorlin handling any copy or paste from keystrokes is actually done entirely by the console, and not by WSL itself. If you're using the regular Windows console, then Ctrl+Shift+C/V feature should be turned on and used for copy and paste from the keyboard, in general Ctrl+V will not work for paste in WSL. If you'd like to use Ctrl+V for paste (and customize other hotkeys) I'd recommend you start using the Windows Terminal as it's possible there. |
As described in the post where we announced Copy & Paste in WSL: Windows Console - the app you see on screen when you run a command-line shell/app behaves differently depending on what shell/app you're running: When using Windows Console connected to Cmd or PowerShell, you can paste text using ctrl+v. When using Windows Console connected to a Linux/WSL instance, if you have checked the relevant checkbox in that Console's "options" properties page, you can paste text using ctrl+shift+v: When using Linux/WSL, Console is set to "raw" mode in which is sends the chars/VT typed into the keyboard input directly to the attached shell/app (i.e. bash running in Ubuntu), and the shell/app then decides what to do with the input. However, many *nix apps use ctrl+v to perform different actions; for example, page-up in emacs. To avoid such 'collisions', we instead 'steal' ctrl+shift+v key chords (which have no direct ASCII/VT representation anyway) and generate the correct paste behavior, sending the text on your clipboard to the shell as if they were typed chars. We provided a way for you to enable/disable this behavior if you ever run a *NIX app which does (somehow/for-some-reason) reserve/require ctrl+shift+v for some pre-defined behavior. If you want to use ctrl+shift+v in all your command-line shells, launch a Console instance (via Cmd or PowerShell), check the associated setting, and hit Ok. |
@bitcrazed thanks for the detailed explanation. Pasting using ctrl+shift+v works as intended. However, the Edit menu (screenshot in #2944 (comment)) still shows ctrl+v as the hotkey for Paste. I know this is Windows Console behavior, but the inconsistency may be confusing for many users. The other issue I referenced (which is unrelated to pasting - let me know if this should be discussed in a new issue) is that extended text selection shift+←/→ does not work in a WSL Console while it works in Powershell/Cmd. |
Alas, there's only so much we can change in the Console before we start breaking someone ... somwhere ... usually somewhere really important and critical. This is one of the main reasons we avoid making UI changes to Console wherever we can, and why we created the new Terminal in the first place: Console's primary job is to preserve backward compatibility. If you want improved/fixed behaviors, we invite you to move to the Terminal where we have MUCH more freedom. Re. your 2nd point - again, this is due to a limitation in how certain key strokes/chords are converted into ANSI/VT sequences: As per https://support.microfocus.com/kb/doc.php?id=7021621#
There are no ANSI/VT sequences for shift+<arrow> keys. However, when attached to Cmd or PowerShell, Console is in "cooked input mode" and is able to communicate to Windows command-line apps that arrow keys were clicked with shift modifiers. Alas, we have no way of introducing a new "lightly-poached input mode" for *NIX apps due to the same reasons as above, so, once again, we encourage you to adopt the new Terminal. |
But why is it so hard to add an option to keep Ctrl+V as paste, and Shift+arrow as select? Hell, untick it by default if you're really that afraid of purists with hay forks and torches coming at you when suddenly their obscure terminal program no longer accepts Shift+left as input for some uninteresting feature and they have to go ALL the way into the options to enable insane input behaviour. The other side of the knife is much sharper, I feel. There are a LOT more people used to cmd.exe on Windows, and simply expect a replacement terminal not to require more effort to do a blatantly simple thing like paste or select. Maybe they are not the kind of people to start a war against Microsoft for not supporting their uninteresting obscure little scripts, but they ARE in much greater numbers. |
Now, please, reopen the issue, and consider doing something about it, because even if by design - a bug is a bug. Be it in the program, or in the design, that bug is still somewhere. |
There is no bug in WSL here. There is, pedantically, a mis-labeled menu in
That has already been explained at length.
Please stop. You aren't even in the right place to bikeshed. |
Your Windows build number: 10.0.16299.214
Bash version: 4.3.48(1)-release-(x86_64-pc-linux-gnu)
"Kernel" version: 4.4.0-43-Microsoft
What you're doing and what's happening: Trying to paste text into the console, but all I'm getting is
^V
, which is probably some archaic escape character that noone needs anymore.What's wrong / what should be happening instead: Pressing Ctrl+V inserts
^V
into the terminal, rather than copied text. Same for Ctrl+Shift+V and Ctrl+Ins. Only the right mouse button successfully pastes text. I would expect Ctrl+V to just paste the copied text, just like in the regular command prompt (cmd.exe) where it works totally fine.Strace of the failing command, if applicable: N/A
My settings in Alt+Space->Properties are default, afaik. But to be clear:
QuickEdit Mode: ticked
Insert Mode: unticked
Enable Ctrl key shortcuts: ticked
Filter clipboard contents on paste: ticked
Enable line wrapping selection: ticked
Extended text selection keys: ticked
Use legacy console: unticked
The text was updated successfully, but these errors were encountered: