Ctrl+V not working

[thany]

• 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

[therealkenc]

#235. User voice is here.

[thany]

@DarthSpock
Ctrl+V works fine in the regular command prompt. So there is some sort of different between it and the WSL console. I wouldn't file a bug like this at the Windows Console, because it's working fine. It's only broken for the WSL terminal. This indicates a bug inside WSL, where maybe Ctrl+V is overridden with whatever.

[edpell]

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.

[onomatopellan]

@edpell Next Feature Update will bring CTRL+SHIFT+C and CTRL+SHIFT+V support.
https://blogs.msdn.microsoft.com/commandline/2018/04/13/copy-and-paste-arrives-for-linuxwsl-consoles/

[thany]

Why Ctrl+Shift+V? Why not make it work the as in the command prompt??

[onomatopellan]

@thany Because Unix terminal has always been like this. CTRL+C and CTRL+V have already a reason to exist different from copy/paste.
https://superuser.com/questions/421463/why-does-ctrl-v-not-paste-in-bash-linux-shell

[thany]

Ctrl+V doesn't do anything in WLS.

Besides, consistency is more important than legacy.
It'll only be confusing if we've got mixed shortcut keys for the same action is VERY similar terminals (cmd vs wls).

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.

[kthy]

Ctrl+V doesn't do anything in WLS.

And yet …

[thany]

That's even weirder. At least the menu is on the right track.
Maybe Ctrl+V doesn't work because in the menu it says "Ctrl minus V" 😀

Anyway,

• Ctrl+Shift+V is different from Command Prompt, so that's undesirable. It would be the same as on most Linux distros, but who cares! It currently inserts ^V into the shell, which is weird but some tool might do something with it, who knows.
• Ctrl+V is the standard, not only in Command Prompt, but also in EVERY other application. Currently it inserts ^V into the shell when hitting Ctrl+V twice, but a single Ctrl+C does absolutely nothing.
• Right mouse click is okay, because it has always worked. Please keep that intact.

To aid users who desperately want Ctrl+Shift+V to paste, let's implement both Ctrl+Shift+V AND Ctrl+V.

[WSLUser]

@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

[kthy]

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

[thany]

@DarthSpock Ctrl+Shift+V also doesn't work.
Besides, I want to use Ctrl+V which would cause me to uncheck that checkbox. And I suspect pasting doesn't work at all then.

[WSLUser]

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.

[thany]

No difference.

Ctrl+V does paste in command prompt, but does not paste in WSL.
Ctrl+Shift+V does not paste in either.

All on the same pc, same network, same user, same day, same moon phase.

[therealkenc]

Ctrl+Shift+V does not paste in either.

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.

[thany]

@therealkenc

WSL (and the Real Linux™ kernel) has never heard of a 'paste', triggered by Ctrl-V or otherwise.

Which is why we can assign it to Paste.

[therealkenc]

Which is why we can assign it to Paste.

The Linux kernel has never heard of "to Paste" either.

[Fun but unrelated trivia: Ctrl-C Ctrl-Z have implications at the kernel via termios and the ioctl(2) syscall, in that they can generate interrupts from the kernel to a process via the tty layer. This is due to quirky historic reasons having to do with control characters sent by teletype terminals.]

"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 ssh. Which is why this issue is closed and tagged console. Since February. And was addressed, it appears, in 17643.

[thany]

@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.

[therealkenc]

Paste is essentially just inserting the characters in the clipboard, into WSL

Paste does not insert anything into WSL; essentially, or otherwise.

[jasamour]

As @thany mentioned

Ctrl+V does paste in command prompt, but does not paste in WSL.
Ctrl+Shift+V does not paste in either.

Strangely, Ctrl+V does paste inside the VS Code integrated terminal (setup to use WSL).

"terminal.integrated.shell.windows": "C:\Windows\System32\wsl.exe"

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!

[therealkenc]

Strangely, Ctrl+V does paste inside the VS Code integrated terminal

Not strange.

This behavior suggests it's the command prompt window Windows Console

Ya think?

and how it processes Ctrl key commands

Correct. The paste operation in Windows Console with WSL is Ctrl+Shift+C/V per Rich's blog post. Which the console team chose to do in order to quoth "ensure that we don't break any existing behaviors". Which is not dissimilar to how wsltty chose to do their paste operation, for the same reasons, although wsltty went with the more traditional paradigm of Ctrl/Shift+Ins. VSCode (actually xtermjs) went with Ctrl-V for their own reasons. xterm still uses the middle mouse button to paste (and most certainly not Ctrl-V), because they're old-school that way. Everyone's prerogative.

once you've invoked the WSL kernel

The WSL kernel has nothing to do with it, and does not know nor does not care what xterm or wsltty or PuTTY or code or the Windows Console chooses to do about cut and paste operations. But people keep posting to this long-since closed-as-a-clam Windows Subsystem for Linux tracker anyway.

[thany]

@therealkenc

Paste does not insert anything into WSL; essentially, or otherwise.

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.

[therealkenc]

Paste does not insert anything into WSL; essentially, or otherwise.
Maybe you're misunderstand my point there.

No I understood you fine.

Clearly it does something when rightclicking

Pronoun. You mean Windows Console. Not WSL. Which is the tracker you're in right now.

They somehow

Mostly Mike I think.

[Mike] somehow inject[s] "typing"

..into the Windows Console. WSL doesn't know about typing either. No keyboard driver.

Some loose ends from earlier posts since I'm here...

^V into the shell, which is weird

Not weird.

but some tool might do something with it,

For example tools like GNU bash(1) or vi(1) or its younger cousin vim(1).

who knows

Pretty much everyone who has used vi since 1976.

Currently it inserts ^V into the shell when hitting Ctrl+V twice,

No, it (the Windows Console) sends a Ctrl-V (hex 0x16) to the tty when you hit that keyboard sequence once. That control code in turn gets picked up by the bash shell according to the lnext (literal next) stty(1) setting. The following character, which might or might not be a second Ctrl-V, gets taken literally. So for example, if you were to type just Ctrl-M (hex 0x0d) you get a carriage return (CR). If you type Ctrl-V Ctrl-M you get an uninterpreted literal Ctrl-M.

but a single Ctrl+C does absolutely nothing.

Ctrl-C (by default) causes a SIGINT to be sent by the tty layer, which, if bash has the tty, gets trapped and causes you to get a new prompt line. If a command (child process of bash) is running and has the tty, a SIGINT is sent to that running process, and depending on the process, usually results in the process exiting but could (in principle) do anything (including nothing) depending on the signal handler.

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.

[thany]

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.
Ctrl+V does work in Powershell
Ctrl+V does NOT work in WSL.

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.

but a single Ctrl+C does absolutely nothing.

I meant Ctrl+V.

No, it (the Windows Console) sends a Ctrl-V (hex 0x16) to the tty when you hit that keyboard sequence once. That control code in turn gets picked up by the bash shell according to the lnext (literal next) stty(1) setting. The following character, which might or might not be a second Ctrl-V, gets taken literally. So for example, if you were to type just Ctrl-M (hex 0x0d) you get a carriage return (CR). If you type Ctrl-V Ctrl-M you get an uninterpreted literal Ctrl-M.

Okay. So instead of sending 0x16, send all characters in the clipboard?... Doesn't seem like rocket science to me. Same as right-click.

[kthy]

accept that paste just doesn't bloody work on WSL

Paste works in WSL. It just has a different keyboard shortcut. This is because of Reasons™.

[therealkenc]

Of course Mike isn't inserting anything into my console.

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 NOT work in WSL.

Ctrl+V does work in WSL (strictly speaking, /bin/bash). bash invokes literal next if that's the stty setting.

ken@DESKTOP-4UTIQSF:~$ stty -a | grep lnext
werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;

but that magical layer in between all of them: WSL

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 0x16 unmolested. ConPTY doesn't know what the Windows Console is doing about paste operations either.

Now please stop arguing about what WSL is or isn't

You perceive an argument where none exists. This WSL tracker has been closed since February.

Okay. So instead of sending 0x16, [it could] send all characters in the clipboard?... Doesn't seem like rocket science to me.

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.

[thany]

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 :)

[tara-raj]

cc @bitcrazed for Console guidance

[victorlin]

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 Ctrl-V hotkey worked, the extended text selection keys (shift-<arrow keys>, etc.) also worked. Now, both these features do not work. This issue is discussed in microsoft/terminal#715. In summary, these two options in Console Windows Properties seem to have no effect.

Windows 10 Build 18362

[craigloewen-msft]

@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.

[bitcrazed]

@victorlin

👉 Note that now Windows Terminal is available from the Microsoft Store, we strongly encourage you to download and start using it if possible: Terminal is undergoing active development, and provides many features that you and others will find useful, including customizable key-mappings.

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.

[victorlin]

@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.

[bitcrazed]

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#

Key	Numeric	ANSI ModeApplication	VT52 ModeCursor or Application
Up	CsiA	Ss3A	EscA
Dn	CsiB	Ss3B	EscB
Rt	CsiC	Ss3C	EscC
Lt	CsiD	Ss3D	EscD

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.

[thany]

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.

[thany]

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.

[therealkenc]

There is no bug in WSL here. There is, pedantically, a mis-labeled menu in cmd.exe. This issue has been closed since 2018 (as a dupe no less) and will not be re-opened.

But why is it so hard to add an option to keep Ctrl+V as paste

That has already been explained at length.

Now, please, reopen the issue

Please stop. You aren't even in the right place to bikeshed.