Wsl on stuartleeks.com

Fun with WSL, GitHub CLI and Windows Notifications

Thu, 27 May 2021 13:42:16 +0100

Introduction

In the last post we saw how to create a drop-in replacement for notify-send. This allowed us to take a script that used notify-send and run it without modification. In this post, we’ll take a look at how we can update that script to take better advantage of Windows notifications.

At the end of that post, the notification was fairly generic as shown below:

Fun with WSL, GitHub CLI and Windows Notifications

Thu, 27 May 2021 07:10:16 +0100

Introduction

I’ve been making use of the GitHub CLI and finding it a productive way to work with GitHub. Recently, Lawrence Gripper shared with me a handy alias that he had set up:

alias ghrun="gh run list | grep \$(git branch --show-current) | cut -d$'\t' -f 8 | xargs gh run watch && notify-send 'Run finished'"

This ghrun alias finds the latest GitHub actions workflow for the current branch and starts a gh run watch for it. This shows the progress through the steps of a workflow:

Forwarding copy to clipboard from dev container to Windows Host

Wed, 17 Feb 2021 19:11:12 +0000

Background

I’ve mentioned VS Code dev containers on this blog before and like using them from WSL.

I’m also a fan of azbrowse for working with Azure resources from the terminal, and lately have found myself running azbrowse from within a dev container for various reasons.

There are several features in azbrowse that copy data to the clipboard, and when run from WSL it detects that and copies to the Windows clipboard, which is convenient. When run from a dev container, the experience isn’t so good (a polite way of saying that it doesn’t work).

Set Windows Terminal to use your user HOME directory

Fri, 09 Oct 2020 12:31:17 +0000

Cross-posted from wsl.tips/tips/windows-terminal-start-directory

Windows Terminal is the new Terminal experience from the Windows team. It’s open source and iterating quickly. As a WSL user, a really nice feature is that it auto-detects the WSL distros you have installed.

By default, when you launch Windows Terminal for a WSL distro it puts you in the /mnt/... path for your Windows user profile (e.g. /mnt/c/Users/stuart).

As this post by Simon Ferquel suggests: “Fully embrace WSL2”! In other words, use the file system in your WSL distro. When you embrace this mindset, having Windows Terminal put you in a mounted Windows path is less helpful - I like to have it default to my HOME directory for the distro.

Forwarding SSH Agent requests from WSL to Windows

Fri, 03 Jul 2020 15:11:12 +0000

Background

As I mentioned in my previous post, I switched to using SSH key auth for GitHub and Azure DevOps Repos a long time ago and found it a positive experience. At first I was a bit lazy and didn’t use passphrases on my keys, and just kept a copy of my keys in the .ssh folder in my User folder in Windows and another copy in ~/.ssh in WSL.

For day-to-day working this worked okay, but I finally got round to adding passphrases to my keys a while back and was less happy with the setup at that point. My previously suppressed niggles around having the keys in multiple places re-surfaced once I had to add handle passphrases in multiple systems on the same machine!

Fixing Clock Skew with WSL 2

Thu, 23 Apr 2020 21:27:16 +0100

Background to the problem

I’m quite a fan of the Windows Subsystem for Linux (WSL), especially WSL version 2 which addresses a bunch of feedback I had for WSL 1. (There’s even a link to a recording of a lightning talk I gave on WSL 2 on the speaking notes page).

However, there’s one issue that continues to bite me: clock skew. With WSL 2 there’s a special VM that Linux runs in that has a bunch of magic sauce applied to make it meld into the Windows environment in ways that a standard VM simply can’t/doesn’t (can you tell that I’m not in the WSL engineering team from that description? 😉). My understanding of the issue is that the clock skew happens when the host machine sleeps/hibernates because the VM for the WSL Linux distro doesn’t have its clock updated when the host resumes.

Visual Studio Code and Dev containers in the Windows Subsystem for Linux (WSL)

Wed, 01 Apr 2020 19:18:23 +0100

UPDATE (2020-04-08): With the 1.44 release of Visual Studio Code (and the corresponding Remote Containers release), the Insiders release is no longer needed as the . I have updated the post to reflect this (update made in vscode dev container on stable release 😁).

Introduction

In my previous post I gave some thoughts on using Visual Studio Code dev containers. Until very recently your source code needed to be cloned in Windows in order to be able to build and run dev containers with Visual Studio Code. While this has still been a great experience overall, I have hit a few edge cases where being able to have my source code in Linux (under WSL) and then create a dev container from there would have been a big help.