win32yank crashes when pasting from vim in WSL #9

lefth · 2019-07-02T04:54:16Z

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.

The text was updated successfully, but these errors were encountered:

tindzk · 2020-07-25T19:00:09Z

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

mangelozzi · 2020-08-22T18:59:46Z

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 · 2021-03-23T02:42:05Z

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 · 2021-03-27T15:07:10Z

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 · 2022-07-03T12:37:57Z

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 · 2022-07-07T17:10:52Z

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 · 2022-10-21T16:25:23Z

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

elevin72 · 2022-10-26T15:59:38Z

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.

plusiv · 2022-11-16T14:20:18Z

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.

elevin72 · 2022-11-17T06:11:58Z

@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 · 2022-12-02T19:50:14Z

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

elevin72 · 2022-12-04T05:46:39Z

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 · 2022-12-21T14:48:16Z

Any fix for this??

elevin72 · 2022-12-21T16:22:56Z

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

plusiv · 2022-12-21T20:26:46Z

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 · 2022-12-21T22:01:22Z

Compile it with cargo

jemag · 2023-01-05T20:53:06Z

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

Would be nice to have a more recent official release

jemag · 2023-01-05T22:00:07Z

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 · 2023-01-06T14:04:59Z

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

gaving · 2023-01-12T14:30:11Z

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 · 2023-01-12T16:37:15Z

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 · 2023-01-16T20:29:35Z

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 · 2023-01-17T10:24:42Z

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 · 2023-01-17T12:36:55Z

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 · 2023-01-17T17:46:05Z

@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 · 2023-01-24T07:57:06Z

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 · 2023-10-10T05:43:09Z

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 🙂

Add Winget Releaser workflow #20

jackblackevo · 2024-04-16T04:20:40Z

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

stevanmilic mentioned this issue Aug 26, 2021

Update clipboard-win to 4.2.1 #11

Closed

RobertBrunhage mentioned this issue Jul 4, 2022

Windows terminal randomly freezes with Neovim 0.6 in debian Bullseye when using MCTRL>-<SHIFT>C or <CTRL-SHIFT>V microsoft/terminal#11945

Closed

einarpersson mentioned this issue Mar 5, 2023

Copy/paste from system clipboard does not work on WSL2 helix-editor/helix#2132

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

win32yank crashes when pasting from vim in WSL #9

win32yank crashes when pasting from vim in WSL #9

lefth commented Jul 2, 2019 •

edited

Loading

tindzk commented Jul 25, 2020

mangelozzi commented Aug 22, 2020 •

edited

Loading

andreykaipov commented Mar 23, 2021

equalsraf commented Mar 27, 2021

RobertBrunhage commented Jul 3, 2022 •

edited

Loading

equalsraf commented Jul 7, 2022

Souhail-JAMHOUR commented Oct 21, 2022

elevin72 commented Oct 26, 2022 •

edited

Loading

plusiv commented Nov 16, 2022

Workaround

elevin72 commented Nov 17, 2022 •

edited

Loading

casret commented Dec 2, 2022

elevin72 commented Dec 4, 2022

plusiv commented Dec 21, 2022

elevin72 commented Dec 21, 2022

plusiv commented Dec 21, 2022

elevin72 commented Dec 21, 2022

jemag commented Jan 5, 2023

jemag commented Jan 5, 2023

yomiikuru-aer commented Jan 6, 2023

gaving commented Jan 12, 2023

gaving commented Jan 12, 2023

jemag commented Jan 16, 2023

yomiikuru-aer commented Jan 17, 2023

plusiv commented Jan 17, 2023

jemag commented Jan 17, 2023

gaving commented Jan 24, 2023

sitiom commented Oct 10, 2023 •

edited

Loading

jackblackevo commented Apr 16, 2024

win32yank crashes when pasting from vim in WSL #9

win32yank crashes when pasting from vim in WSL #9

Comments

lefth commented Jul 2, 2019 • edited Loading

tindzk commented Jul 25, 2020

mangelozzi commented Aug 22, 2020 • edited Loading

andreykaipov commented Mar 23, 2021

equalsraf commented Mar 27, 2021

RobertBrunhage commented Jul 3, 2022 • edited Loading

equalsraf commented Jul 7, 2022

Souhail-JAMHOUR commented Oct 21, 2022

elevin72 commented Oct 26, 2022 • edited Loading

Workaround

plusiv commented Nov 16, 2022

Workaround

elevin72 commented Nov 17, 2022 • edited Loading

casret commented Dec 2, 2022

elevin72 commented Dec 4, 2022

plusiv commented Dec 21, 2022

elevin72 commented Dec 21, 2022

plusiv commented Dec 21, 2022

elevin72 commented Dec 21, 2022

jemag commented Jan 5, 2023

jemag commented Jan 5, 2023

yomiikuru-aer commented Jan 6, 2023

gaving commented Jan 12, 2023

gaving commented Jan 12, 2023

jemag commented Jan 16, 2023

yomiikuru-aer commented Jan 17, 2023

plusiv commented Jan 17, 2023

jemag commented Jan 17, 2023

gaving commented Jan 24, 2023

sitiom commented Oct 10, 2023 • edited Loading

jackblackevo commented Apr 16, 2024

lefth commented Jul 2, 2019 •

edited

Loading

mangelozzi commented Aug 22, 2020 •

edited

Loading

RobertBrunhage commented Jul 3, 2022 •

edited

Loading

elevin72 commented Oct 26, 2022 •

edited

Loading

elevin72 commented Nov 17, 2022 •

edited

Loading

sitiom commented Oct 10, 2023 •

edited

Loading