win32yank crashes when pasting from vim in WSL

[lefth]

win32yank cannot consistently paste text, if the text was copied using vim or neovim in WSL. To reproduce, open vim in WSL. Type a line such as "test", then use "*yy to yank the line into the system clipboard. In another window, execute:

win32yank.exe -o

Running the command repeatedly, half the time the line it pasted. The other half of the time, the following error is shown:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: WinAPI Error(6)', src\libcore\result.rs:859
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: BaseThreadInitThunk

The problem occurs even when invoking win32yank from CMD.exe.

[tindzk]

Have you tried WSL2? win32yank 0.4.0 works for me reliably with NVIM v0.5.0-613-g44cbf288e under ArchWSL.

[mangelozzi]

I'm WSL2, Ubuntu 20.04, NVIM v0.5.0-563-ge628a05b5, recent win32yank version (how do I check the version)?

And I at about once every 2 hours while coding get:

clipboard: error invoking win32yank.exe: thread 'main' panicked at 'called `Result::unwrap()` on
an `Err` value: WinAPI Error(1418)', src\libcore\result.rs:859 note: Run with 
`RUST_BACKTRACE=1` for a backtrace. Press ENTER or type command to continue

[andreykaipov]

Just experienced the same error above by holding x. Not really a big deal at all, but figured I'd share.

Reproduceable outside of Neovim, but setting RUST_BACKTRACE=1 doesn't give any additional output though:

❯ (export RUST_BACKTRACE=1; for i in $(seq 1 10); do echo | win32yank.exe -i & done)
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: WinAPI Error(1418)', src\libcore\result.rs:859
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread 'thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: WinAPI Error(1418)', src\libcore\result.rs:859
note: Run with `RUST_BACKTRACE=1` for a backtrace.
main' panicked at 'called `Result::unwrap()` on an `Err` value: WinAPI Error(1418)', src\libcore\result.rs:859
note: Run with `RUST_BACKTRACE=1` for a backtrace.

It's also an error 1418 if we do quick pastes, so this is probably different than OP's issue as that's an error 6.

[equalsraf]

This is proving to be a challenge since I no longer have a working windows machine.

It is probably easier to enable the neovim-qt native clipboard in your settings by putting call GuiClipboard() in ginit.vim

[RobertBrunhage]

This still seems to be an issue, any updates regarding it?

I've compiled a version 0.0.5 that is from the above PR, at least it works consistently now!

[equalsraf]

The reason why the PR was not merged at the time was because one of the tests was failing e.g. https://ci.appveyor.com/project/equalsraf/win32yank/builds/44095635/job/0qnt0s68ckhlnasr

[Souhail-JAMHOUR]

Hey i know its abit off the issues but does anyone have an idea of this arguments issue

[elevin72]

Hi! It seems I found some people encountering the same issues I have been dealing with for the past few days. When pasting from a copy inside of neovim, the entire terminal intermittently freezes and I have to close the entire window (usually losing work). I have noticed the bug happens in 2 ways:

1. When doing a basic vim copy paste. yy to copy and p to paste. The entire terminal tab containing neovim freezes and seems to never recover until closing it and opening again.

2. When doing a copy from neovim to another terminal. This terminal can be located inside neovim or not, it seems to not matter. If I do C-v the entire terminal crashes. If I run win32yank.exe -o in a separate terminal I get:

   thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: WinAPI Error(0)', src\main.rs:121:51
   note: run with `RUST_BACKTRACE=1` environment variable to display a `backtrace

   I am using neovim 0.7.3 in wsl2. I have been using Windows Terminal and Wezterm, and I see the issue in both, but it seems worse on Windows Terminal.

Workaround

I (think) I have found a workaround by editing my init.lua as follows:

1. Removing set clipboard=unnamedplus

2. Adding the snippet that I found in this gist

let g:clipboard = {
                        \   'name': 'win32yank-wsl',
                        \   'copy': {
                        \      '+': 'win32yank.exe -i --crlf',
                        \      '*': 'win32yank.exe -i --crlf',
                        \    },
                        \   'paste': {
                        \      '+': 'win32yank.exe -o --lf',
                        \      '*': 'win32yank.exe -o --lf',
                        \   },
                        \   'cache_enabled': 0,
                        \ }

Now y does not copy to system clipboard, but "+y (which I remapped to \<leader>y) does and so far I have not seen any crashes. If I do see crashes in the future from this workaround I'll try to update.

[plusiv]

Hi! It seems I found some people encountering the same issues I have been dealing with for the past few days. When pasting from a copy inside of neovim, the entire terminal intermittently freezes and I have to close the entire window (usually losing work). I have noticed the bug happens in 2 ways:

1. When doing a basic vim copy paste. yy to copy and p to paste. The entire terminal tab containing neovim freezes and seems to never recover until closing it and opening again.
2. When doing a copy from neovim to another terminal. This terminal can be located inside neovim or not, it seems to not matter. If I do C-v the entire terminal crashes. If I run win32yank.exe -o in a separate terminal I get:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: WinAPI Error(0)', src\main.rs:121:51
note: run with `RUST_BACKTRACE=1` environment variable to display a `backtrace

I am using neovim 0.7.3 in wsl2. I have been using Windows Terminal and Wezterm, and I see the issue in both, but it seems worse on Windows Terminal.

Workaround

I (think) I have found a workaround by editing my init.lua as follows:

1. Removing set clipboard=unnamedplus
2. Adding the snippet that I found in this gist

let g:clipboard = {
                        \   'name': 'win32yank-wsl',
                        \   'copy': {
                        \      '+': 'win32yank.exe -i --crlf',
                        \      '*': 'win32yank.exe -i --crlf',
                        \    },
                        \   'paste': {
                        \      '+': 'win32yank.exe -o --lf',
                        \      '*': 'win32yank.exe -o --lf',
                        \   },
                        \   'cache_enabled': 0,
                        \ }

Now y does not copy to system clipboard, but "+y (which I remapped to y) does and so far I have not seen any crashes. If I do see crashes in the future from this workaround I'll try to update.

It works for me, but it paste clipboard content too slow.

[elevin72]

@Jorgmassih it is pretty slow, sometimes taking almost a second to copy a larger amount of text. I'm not sure if the delay is from nvim or from win32yank Thankfully I am usually doing native nvim copying, and I haven't seen lagginess there.

[casret]

Hit this problem this morning and a simple echo hello | win32yank -i is taking 12 seconds. What could've changed here?

[elevin72]

Hit this problem this morning and a simple echo hello | win32yank -i is taking 12 seconds. What could've changed here?

Maybe try compiling from one of the PR's which update to clipboard-win 4.x . I'm pretty sure I did something similar and it works somewhat faster. It's not instant the way copy/paste should be, but it's very usable.

[plusiv]

Any fix for this??

[elevin72]

One of those PR's was merged. Downloading the latest version of this program should be a good bet

[plusiv]

One of those PR's was merged. Downloading the latest version of this program should be a good bet

Yep, but I didn't see any official release in the Releases Section. I don't know if the work is completely finished by the devs.

[elevin72]

Compile it with cargo

[jemag]

Cannot build it, seems to be the case for others as well : https://github.com/equalsraf/win32yank/issues/17.

Would be nice to have a more recent official release

[jemag]

Managed to build the latest version. Did not fix the problem for me however, still takes around 12 seconds to send anything to win32yank

[yomiikuru-aer]

I have the same issue. Taking forever to paste any text size.

[gaving]

Hit this problem this morning and a simple echo hello | win32yank -i is taking 12 seconds. What could've changed here?

I've now some random freezing going on with my WSL2 ever since some patch update.

Can't narrow it down with any logs but will try building this latest version and see if it fixes anything!

[gaving]

I've stuck a latest build of head here: https://gist.github.com/gaving/9870731d9c9d48e5fd04c1907b2357cf/raw/e8a9facbf20fc7044cf7a804a38ed8abc6900fbc/win32yank.zip

However wont get a chance to test this myself for a week! 🤞

[jemag]

So although I always used to have win32yank installed on the Linux side and it worked fine, I did have the delay problem lately with latest WSL.

However, removing it from the Linux side and just installing it on the windows side with Scoop now works fine without delay for me. Basically the Linux side is just pointing to the win32yank installed on Windows like so:

Seems to work fine so far.

[yomiikuru-aer]

So although I always used to have win32yank installed on the Linux side and it worked fine, I did have the delay problem lately with latest WSL.

However, removing it from the Linux side and just installing it on the windows side with Scoop now works fine without delay for me. Basically the Linux side is just pointing to the win32yank installed on Windows like so:

Seems to work fine so far.

This works, thanks!

[plusiv]

So although I always used to have win32yank installed on the Linux side and it worked fine, I did have the delay problem lately with latest WSL.

However, removing it from the Linux side and just installing it on the windows side with Scoop now works fine without delay for me. Basically the Linux side is just pointing to the win32yank installed on Windows like so:

Seems to work fine so far.

Did you just added win32yank.exe path location to your Linux $PATH env variable ?

[jemag]

@plusiv with my current WSL setup this was done automatically, but yes you could just add it to your path or symlink it to somewhere where you already store binaries accessible in path.

[gaving]

Can confirm that the latest build didn't fix this for me, but moving it outside WSL space as suggested by @jemag appears to have done the trick.

Strange issue!

[sitiom]

However, removing it from the Linux side and just installing it on the windows side with Scoop now works fine without delay for me.

I have just added win32yank to Winget too (https://github.com/microsoft/winget-pkgs/pull/108528). You can try that as well 🙂

Related:

• 20

[jackblackevo]

However, removing it from the Linux side and just installing it on the windows side with Scoop now works fine without delay for me.

I have just added win32yank to Winget too (microsoft/winget-pkgs#108528). You can try that as well 🙂

Related:

• Add Winget Releaser workflow #20

Thank you! Now I can easily install it in WSL 2:

winget.exe install win32yank