win32yank crashes when pasting from vim in WSL

Question

win32yank crashes when pasting from vim in WSL

lefth opened this issue 5 years ago · 28 comments

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.

Answer 1 · 2020-07-25T19:00:09.000Z

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

Answer 2 · 2020-08-22T18:59:46.000Z

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

Answer 3 · 2021-03-23T02:42:05.000Z

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.

Answer 4 · 2021-03-27T15:07:10.000Z

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

Answer 5 · 2022-07-03T12:37:57.000Z

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!

Answer 6 · 2022-07-07T17:10:52.000Z

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

Answer 7 · 2022-10-21T16:25:23.000Z

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

Answer 8 · 2022-10-26T15:59:38.000Z

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:

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

Removing set clipboard=unnamedplus
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.

Answer 9 · 2022-11-16T14:20:18.000Z

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:

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.

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:

Removing set clipboard=unnamedplus

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.

Answer 10 · 2022-11-17T06:11:58.000Z

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

Answer 11 · 2022-12-02T19:50:14.000Z

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

Answer 12 · 2022-12-04T05:46:39.000Z

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.

Answer 13 · 2022-12-21T14:48:16.000Z

Any fix for this??

Answer 14 · 2022-12-21T16:22:56.000Z

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

Answer 15 · 2022-12-21T20:26:46.000Z

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.

Answer 16 · 2022-12-21T22:01:22.000Z

Compile it with cargo

Answer 17 · 2023-01-05T20:53:06.000Z

Cannot build it, seems to be the case for others as well : #17.

Would be nice to have a more recent official release

Answer 18 · 2023-01-05T22:00:07.000Z

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

Answer 19 · 2023-01-06T14:04:59.000Z

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

Answer 20 · 2023-01-12T14:30:11.000Z

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!

Answer 21 · 2023-01-12T16:37:15.000Z

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! 🤞

Answer 22 · 2023-01-16T20:29:35.000Z

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.

Answer 23 · 2023-01-17T10:24:42.000Z

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!

Answer 24 · 2023-01-17T12:36:55.000Z

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 ?

Answer 25 · 2023-01-17T17:46:05.000Z

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

Answer 26 · 2023-01-24T07:57:06.000Z

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!

Answer 27 · 2023-10-10T05:43:09.000Z

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 🙂

#20

Answer 28 · 2024-04-16T04:20:40.000Z

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