Trying WSL2, Two Missing Pieces

Posted on Dysfunctional Programming 2021-08-27

On my current development workstation[0] I have tried almost all major operating systems, from macOS (Hackintosh) to illumos. As a desktop environment all are terrible. Considering my hardware and peripherals, I’ve never really had too much of a problem with Linux, my default choice for the last decade and my current target deployment platform, but it turns out that even when running a Hackintosh, everything is just better. This isn’t to say that there aren’t some things that Linux is better at even on the desktop, but generally no single environment really satisfies me, and in fact generally annoys me with bugs, bad performance and inconsistencies.

Recently I tried WSL2 again. The landscape has changed over the years and I’ve found that the latest state of things in Windows 10 actually works out quite nicely for me. When I’m developing outside of a browser I don’t stray too far from the terminal, so when I’m running Vim and my development tools inside tmux, it’s just Linux. I get the exact same experience as I would on Ubuntu, but my bluetooth earbuds, my webcam and hardware acceleration just work and really well too. In a typical day I don’t need to cross the file-system boundary and when I do it’s either because I’m running a background backup job with rsync in Linux transferring files to an NTFS formatted external USB drive or I’m viewing Linux-hosted content in Chrome/Firefox/Edge on Windows. TCP port forwarding is handled transparently and for local files you can use the //wsl$ network mount, in either case I haven’t noticed any performance issues at all. Once I had set up everything, there were two missing pieces left.

Hotkeys

In my experience both macOS and Windows have terrible out of the box support for custom hotkeys. I tend to use keyboards that don’t have any kind of dedicated multimedia keys or function key modifiers, or if they do, require you to do some kind of finger gymnastics to invoke them. This is why I have my own scheme that I can setup as needed anywhere. On pretty much every other operating system, because of X, this is trivial. Either the desktop environment has an interface or a configuration file you can use to define your hotkeys. Alternatively you can use a more generic solution such as xbindkeys. Wayland clients also have their own implementations. The last time I tried Windows, I used Microsoft PowerToys, but aside from including lots of other stuff that I didn’t need, there were certain limitations that I came up against, such as the inability to define a 4-key binding, which for my scheme at least, is a requirement.

I’ve now settled on AutoHotKey, an application I had heard about but never used and which addresses the requirement perfectly, here’s my current configuration:

^!N::Media_Prev
^!n::Media_Next
^!p::Media_Play_Pause
^!y::Volume_Down
^!u::Volume_Up
^!t::Run, alacritty.exe

You just enter this into a file ending .ahk, create a shortcut to that file and place it in the startup folder (Win + R shell:startup).

“Shared” Clipboard

The other small missing piece was a shared clipboard between Windows and Linux. Now, you can of course copy and paste in a terminal window, whether running WSL via cmd, PowerShell, Alacritty or others, but what I was missing specifically is the ability to pipe in and out of the clipboard on the command line. So what you get with xclip or xsel on X or pbcopy/pbpaste on macs.

On Linux my tmux config includes these lines:

set-option -g mouse on
set-option -s set-clipboard off
bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "xclip -se ci -i"

It basically allows you to select with the mouse (or using keybindigs with vi mode enabled) and copy into the clipboard the selection you’ve made. It’s a small feature but for me a massive productivity boost and something I use all the time, so without xclip or similar on Windows I missed it.

I already knew that you could refer to .exes in WSL and it would interact with the application on the Windows side[1], so I began investigating the Win32 C APIs required to do this programmatically[2] but after a quick search I found out about clip.exe which is the native out of the box solution to xclip. I made a very simple tweak to my config:

bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "clip.exe"

…and everything just works as expected.

0 a refurbished HP Elite Ivy Bridge system with a load of extra RAM.

1 as an example, instead of xdg-open . that I use regularly for opening the current directory in the file explorer, you can do explorer.exe ..

2 I’m comfortable with C but totally unfamiliar with Win32. I also considered cross-platform solutions in Rust or Go.


Copyright © 2018 - 2021, Rory Bradford.