Copying with clip.exe in WSL 2 results in garbled characters

[nickjj]

This plugin uses clip.exe when in WSL 2.

I noticed when copying emojis or something like the output of tree with tmux-yank the characters would get garbled. I never looked into it too deeply but a few sources say clip.exe doesn't handle UTF-8 encoded text properly so characters outside of the basic ASCII range get messed up.

You can verify this.

1. Copy unicode characters that get garbled:

echo "├── test" | clip.exe

2. Paste the text anywhere (in Windows notepad, your terminal in WSL 2, Neovim in WSL 2, etc.):

Γö£ΓöÇΓöÇ test

I'd suggest not having a hard coded case for WSL 2 or at the very least move clip.exe to the last condition so if you have xclip installed in WSL 2 it will use that, and then clip.exe can be treated as a fallback plan.

WSL 2 is a Linux system and folks can follow the Linux instructions. WSL 2 has WSLg available which supports clipboard sharing between Windows and WSL so there's no extra steps to follow other than to install any Linux clipboard tool such as xclip.

Workaround proof of concept

I was able to modify script/helpers.sh by commenting out these lines:

    # elif command_exists "clip.exe"; then # WSL clipboard command
    #     echo "cat | clip.exe"

Once I did that, emojis and other unicode characters were copied correctly because I have xclip installed in WSL 2.

[airglow923]

I think this is due to clip.exe not supporting UTF-8. Same issue microsoft/WSL#11047 in WSL repo.

This one works:

echo "├── test" | iconv -f utf8 -t utf16le | clip.exe

[nickjj]

Yep that looks related.

I didn't try it but enabling UTF-8 support in Windows itself might be something to look into to avoid needing to pipe things to iconv. Apparently that's a beta feature: https://exploratory.io/note/exploratory/Enabling-UTF-8-on-Windows-hYc3yWL0