Skip to main content

WSL: Interop state of mind

Introduction

while playing with Docker and the Named Pipe trick, I wanted to give a more "*nix" feeling of Craig Wilhite volume mounting example:
$ docker run -v C:/Users/crwilhit.REDMOND/tmp/ microsoft/nanoserver cmd.exe
There's nothing wrong with this command, but the "scope" is WSL shell, and while using the docker nix command, the path of the volume is the windows one.
There should be a better way, no?

WSLENV to save the day

Luckily, the WSL team did already implement a very nice feature, WSLENV, and a linux command, wslpath that will help translating the Windows path.

Now it would be up to you to either create, in Windows, an environment variable and use it.
Here is the same example, using LCOW (because why not), for mounting volumes in a "linux way":
$ docker run --platform=linux -it -v $DOCKERVOL/mydir:/sharedvol ubuntu bash
or use the wslpath command:
$ docker run --platform=linux -it -v `wslpath -w /mnt/c/DockerVolumes/mydir`:/sharedvol ubuntu bash

Mixing all and having fun

Playing with the paths, is nice, but it's a tweet from the legendary Scott Hanselman that triggered an idea even crazier: try the same with windows commands in WSL shell.

First of all, we need to understand what I call the "scope" between a command and the shell used to run it.
In Scott's example, he's piping a value from a windows command (dir) to a bash one (grep).
The pipe, is a Shell function, not related to the command itself.

So with that in mind, here is the example from before but with docker.exe from WSL:
$ docker.exe run --platform=linux -it -v `wslpath -w /mnt/c/DockerVolumes/mydir`:/sharedvol ubuntu bash"
As we are in WSL scope, the command substitution will be interpreted successfully and then the windows command will run thanks to the interopability.
The end command would be something like:
$ docker.exe run --platform=linux -it -v C:\DockerVolumes\mydir:/sharedvol ubuntu bash
This means that you will be able to use bash variables with Windows commands too.

Restrictions

With all that said, there's still some restrictions that really need to be known:
  1. The directories have to be in the Windows visible FS. Anything in /mnt/<drive letter>/... is OK
  2. If you're using Powershell as the default, you will have to do like Scott shown in his example: put "wsl.exe" before your linux command. You need to define the scope.
  3. Just concerning the Docker examples, the volume sharing has to be in Windows path format for both commands (linux and windows).
    See Craig's notes on his blog.

Conclusion

The more WSL is evolving, the more I see no boundaries in Interop and I'm really looking forward to the first linux and/or windows applications that would use this capability natively.

Last but not least, Interop is really a state of mind. If you can look beyond the "walls" separating both worlds and instead embrace the fact that water and oil can mix, believe me when I tell you that the fun is infinite.
Ok, and a weird mind can help having crazy ideas...


>>> Nunix Out <<<

Comments

Popular posts from this blog

WSL: One Home to host them all

Introduction This blog post will explain how a single home mount can be shared accross all  the WSL instances. It was quite fun to find the idea and then make it happen. It will use all the tools currently available from WSL, so please don't expect a "Linux only" as Interopability will be heavily used. And before I start, here is my point of view about WSL: It's not only  Linux! It's different, just like GNU is different from Unix (yes I said it). We have finally the strength of both worlds combined. And while I do understand the "dev" aspect is meant to be reproducible in a Linux prod environment, the "ops" side is meant to take advantages of everything that can make the full environment feeling Home. Setup requirements In order to really enjoy this solution, I do recommend having 2 or more WSL distros installed or, if you fell like a real WSLCorsair, try @bketelsen crazy setup (I love it)! While the distros are downlo

Docker + WSL: Get 2 daemon for the price of 1

Introduction almost two years ago, Docker announced the capability of switching between the Linux and Windows containers "mode" (far from the right click that we have today). At that time, I wrote a blog post on how to run both daemons at the same time ( http://darthnunix.blogspot.ch/2016/10/docker-for-windows-2-daemons-enter-in.html ) Fast forward to 2018, and while we were blogging on how to get the TLS connection from WSL docker client with  Rory McCune  ( https://raesene.github.io/blog/2018/03/29/WSL-And-Docker/ ), another blog post, by Stefan Stranger drew my attention (read: blew my mind) as I was trying to reproduce the same: how could I "bind" the docker socket in WSL with the Docker for Windows Linux mode socket ( https://blogs.technet.microsoft.com/stefan_stranger/2018/04/02/access-my-docker-for-windows-kubernetes-cluster-from-debian-wsl/ ) From 1 to 2 daemon: DemonHunter mode achieved Now that we have all the required setup resources, let's b

Secure nested LCOW: Part 3

Part 3: Getting all together After the configuration of the Docker daemon on the Nested Hyper-V VM ( part 2 ), it's now finally time to configure the Docker client that will connect to it. Once again, I will be using WSL as the main shell. However, if you choose to go with Powershell, it's OK too (simply I won't explain it here :). Setup: Window 10 Docker Client first of all, the docker client needs to be installed in the WSL environment. And this will be as easy as one command line, thanks to the Docker install script: client:~$ curl -sSL https://get.docker.com/ | sudo sh As the end of the log suggests, add your user to the docker group. This will require you to logoff in order to apply the change. You can either close the WSL console window and open a new one (logoff / login), or a small trick is to "login again" using the "su" command: client:~$ sudo usermod -aG docker $LOGNAME client:~$ sudo su - $LOGNAME Generate Docker client