430 lines
29 KiB
Markdown
430 lines
29 KiB
Markdown
---
|
||
title: The Ultimate Guide to Windows Subsystem for Linux (Windows WSL)
|
||
source: https://adamtheautomator.com/windows-subsystem-for-linux/
|
||
---
|
||
|
||
## [The Ultimate Guide to Windows Subsystem for Linux (Windows WSL)](https://adamtheautomator.com/windows-subsystem-for-linux/)
|
||
|
||
The Windows Subsystem for Linux or Windows WSL is a great solution for developers to natively work within Linux right on their Windows 10 version desktop.
|
||
|
||
If you’ve spent way too much time partitioning hard drives to have several Linux systems installed with Windows, you’re in luck with this article.
|
||
|
||
The fairy code-mother at Microsoft has decided to give you another option: [The Windows Subsystem for Linux (WSL)](https://docs.microsoft.com/en-us/windows/wsl/faq). WSL makes running a Linux system alongside Windows so much easier, and more flexible.
|
||
|
||
In this tutorial, you’ll learn how to get started with WSL. You’ll learn how to get started to learning how to use some nifty tools making WSL even more versatile than using bash or PowerShell on their own.
|
||
|
||
- [What is WSL?](#What_is_WSL "What is WSL?")
|
||
- [How to Enable WSL](#How_to_Enable_WSL "How to Enable WSL")
|
||
- [Prerequisites](#Prerequisites "Prerequisites")
|
||
- [Enabling the WSL Windows Feature](#Enabling_the_WSL_Windows_Feature "Enabling the WSL Windows Feature")
|
||
- [Downloading a Linux Distribution for WSL](#Downloading_a_Linux_Distribution_for_WSL "Downloading a Linux Distribution for WSL")
|
||
- [Setting your WSL Version](#Setting_your_WSL_Version "Setting your WSL Version")
|
||
- [Starting up WSL](#Starting_up_WSL "Starting up WSL")
|
||
- [Sharing Windows/Linux Resources via WSL](#Sharing_WindowsLinux_Resources_via_WSL "Sharing Windows/Linux Resources via WSL")
|
||
- [Sharing File Systems](#Sharing_File_Systems "Sharing File Systems")
|
||
- [Finding the Linux File System from Windows with Environment Variables](#Finding_the_Linux_File_System_from_Windows_with_Environment_Variables "Finding the Linux File System from Windows with Environment Variables")
|
||
- [Finding the Linux File System from Windows via the Microsoft Store Packages Folder](#Finding_the_Linux_File_System_from_Windows_via_the_Microsoft_Store_Packages_Folder "Finding the Linux File System from Windows via the Microsoft Store Packages Folder")
|
||
- [Finding the Windows File System from Linux](#Finding_the_Windows_File_System_from_Linux "Finding the Windows File System from Linux")
|
||
- [The WSL2 Filesystem](#The_WSL2_Filesystem "The WSL2 Filesystem")
|
||
- [Sharing Environment Variables](#Sharing_Environment_Variables "Sharing Environment Variables")
|
||
- [Overview](#Overview "Overview")
|
||
- [Sharing Options](#Sharing_Options "Sharing Options")
|
||
- [Path Translation](#Path_Translation "Path Translation")
|
||
- [Sharing and Translating Windows Paths with Linux](#Sharing_and_Translating_Windows_Paths_with_Linux "Sharing and Translating Windows Paths with Linux")
|
||
- [Sharing and Translating Linux Paths with Windows](#Sharing_and_Translating_Linux_Paths_with_Windows "Sharing and Translating Linux Paths with Windows")
|
||
- [Sharing Network Resources](#Sharing_Network_Resources "Sharing Network Resources")
|
||
- [Physical vs. Virtualized Network Interfaces](#Physical_vs_Virtualized_Network_Interfaces "Physical vs. Virtualized Network Interfaces")
|
||
- [Client DNS Resolution](#Client_DNS_Resolution "Client DNS Resolution")
|
||
- [Using PowerShell and Bash Together](#Using_PowerShell_and_Bash_Together "Using PowerShell and Bash Together")
|
||
- [PowerShell –> Bash](#PowerShell_-%3E_Bash "PowerShell –> Bash")
|
||
- [Bash –> PowerShell/Cmd](#Bash_-%3E_PowerShellCmd "Bash –> PowerShell/Cmd")
|
||
- [Translation Issues](#Translation_Issues "Translation Issues")
|
||
- [Install a Windows Subsystem for Linux GUI with Xfce4](#Install_a_Windows_Subsystem_for_Linux_GUI_with_Xfce4 "Install a Windows Subsystem for Linux GUI with Xfce4")
|
||
- [Xfce](#Xfce "Xfce")
|
||
- [xRDP](#xRDP "xRDP")
|
||
- [Setting Up](#Setting_Up "Setting Up")
|
||
- [Tips and Tricks](#Tips_and_Tricks "Tips and Tricks")
|
||
- [Setting WSL Configuration Items at Bootup with wsl.conf](#Setting_WSL_Configuration_Items_at_Bootup_with_wslconf "Setting WSL Configuration Items at Bootup with wsl.conf")
|
||
- [Developing on WSL with Visual Studio Code (VS Code)](#Developing_on_WSL_with_Visual_Studio_Code_VS_Code "Developing on WSL with Visual Studio Code (VS Code)")
|
||
- [Adding Windows Subsystem for Linux to the Windows Terminal](#Adding_Windows_Subsystem_for_Linux_to_the_Windows_Terminal "Adding Windows Subsystem for Linux to the Windows Terminal")
|
||
- [Closing Thoughts](#Closing_Thoughts "Closing Thoughts")
|
||
|
||
## What is **WSL?**
|
||
|
||
WSL or *C:\\Windows\\System32\\wsl.exe* is a Windows tool that allows you to install a Linux distribution as an app from the Windows store.
|
||
|
||
Since WSL is a simple Windows executable, you can call it from a command prompt or PowerShell terminal. We’ll go deeper into that topic later. For now, it’s important to understand a little more about what WSL is doing under the hood.
|
||
|
||
<img width="912" height="409" src="../../_resources/wsl-1_005355798dca45b698813d61892ef663.png"/>
|
||
|
||
*wsl.exe*
|
||
|
||
## How to Enable **WSL**
|
||
|
||
To set up and enable WSL involves installing a Linux distribution alongside Windows 10. But in a way that allows the two different operating systems to interact with each other.
|
||
|
||
### Prerequisites
|
||
|
||
To install WSL on Windows, you have one requirement to meet; you must have a Windows 10 64-bit computer Build 18917 or later.
|
||
|
||
You can find your Windows 10 build by running the winver utility.
|
||
|
||
<img width="912" height="470" src="../../_resources/image-1_ea78ba9c8e064e6fb39f48ce5f8b8696.png"/>
|
||
|
||
Windows build 1809
|
||
|
||
### Enabling the WSL Windows Feature
|
||
|
||
WSL is a cinch to enable; no download required. It’s simply a single Windows feature.
|
||
|
||
To enable WSL, open up PowerShell as administrator and run the following:
|
||
|
||
```
|
||
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
|
||
```
|
||
|
||
***Related: [How to Run PowerShell as Administrator](https://adamtheautomator.com/powershell-run-as-administrator/)***
|
||
|
||
Once complete, restart your computer and you’re done!
|
||
|
||
### Downloading a Linux Distribution for WSL
|
||
|
||
WSL does not install any Linux distribution on its own. You’ll need to install one. Once Windows 10 comes back up, start setting up your chosen Linux distribution.
|
||
|
||
First, open up the [Microsoft Store](https://www.microsoft.com/en-us/store/apps/windows) and [search for ‘WSL’](https://www.microsoft.com/en-us/search/shop/apps?q=wsl). You should soon see a list of Linux distributions show up.
|
||
|
||
<img width="912" height="431" src="../../_resources/image-2-1024x484_f44a8e002df5421796bf0cd5443bd521.png"/>
|
||
|
||
Next, choose your distribution of choice and install it. This tutorial will be using Ubuntu 18.04. At the time of this writing, you have a few other distributions available as well such as:
|
||
|
||
- Ubuntu 16.04 LTS
|
||
- Ubuntu 18.04 LTS
|
||
- OpenSUSE Leap 15
|
||
- OpenSUSE Leap 42
|
||
- SUSE Linux Enterprise Server 12
|
||
- SUSE Linux Enterprise Server 15
|
||
- Kali Linux
|
||
- Debian GNU/Linux
|
||
- Fedora Remix for WSL
|
||
- Pengwin
|
||
- Alpine WSL
|
||
|
||
#### Setting your WSL Version
|
||
|
||
You might have to enable Linux to work with WSL version 2. If so, you can do so by following the below instructions.
|
||
|
||
In a PowerShell console:
|
||
|
||
1. List which versions of Linux you have installed by running `wsl -l` or `wsl --list`.
|
||
2. Once you have the list, copy the name of the distro you want to run with WSL2 and run `wsl --set-version <Distro> 2`, replacing <Distro> with the name you copied earlier.
|
||
3. Confirm the command was successful by running `wsl -l -v` or `wsl --list --verbose`. This command will return a full list of WSL distros and the version each distro is using.
|
||
|
||
<img width="912" height="194" src="../../_resources/revert-linux-distro-wsl_91f0260f76fd48308ef0d8c7b6.png"/>
|
||
|
||
Setting WSL Linux distro
|
||
|
||
> *You can also set your default WSL version for any distros you install in the future to WSL2 by running `wsl --set-default-version 2`*
|
||
|
||
## Starting up WSL
|
||
|
||
To start using WSL, open up a PowerShell terminal and type `wsl`. If you’ve set up WSL correctly, you’ll enter a bash terminal running on the WSL distro of choice. From here, you can run any Linux commands you wish.
|
||
|
||
Below you will find a reference to all of the options the *wsl.exe* provides when starting up.
|
||
|
||
| Command | Explanation | Example |
|
||
| --- | --- | --- |
|
||
| exec, -e | Will run command using without using default shell | wsl -e curl google.com |
|
||
| — | Passes anything after this parameter to default shell. Leaving the operator out will also work. | wsl — curl google.com, wsl curl google.com |
|
||
| distribution, -d | Opens a terminal in the specified distribution’s shell | wsl -d Ubuntu-18.04 |
|
||
| user, -u | Runs WSL command as the specified user as long as user exists on that distro | wsl -d Ubuntu-18.04 -u tux_user |
|
||
| export | Exports the specified distribution to a tar file on your local system. | wsl –export Ubuntu ./Test-Ubuntu.tar |
|
||
| import \[–version\] | Imports a tar file as a new WSL distribution. Can specify WSL version with the –version option | wsl –import Test-Ubuntu C:\\data\\Test-Ubuntu .\\Test-Ubuntu.tar |
|
||
| list, -l \[Options\] | wsl –list | |
|
||
| all | List all installed WSL distributions | wsl -l –all |
|
||
| running | List only WSL distributions that are currently running | wsl -l –running |
|
||
| quiet, -q | Only show WSL distribution names | wsl -l -q |
|
||
| verbose, -v | Show detailed information about all WSL distributions | wsl -l -v |
|
||
| set-default, -s | Sets the specified WSL distribution as the default distribution for WSL commands. | wsl -s Test-Ubuntu |
|
||
| set-default-version | Changes the default WSL version for all new distributions installed to that system | wsl –set-default-version 2 |
|
||
| set-version | Changes the WSL version of the specified distribution | wsl –set-version Test-Ubuntu 2 |
|
||
| shutdown | Immediately terminates all running WSL distributions | wsl –shutdown |
|
||
| terminate, -t | Terminates the specified WSL distribution | wsl -t Test-Ubuntu |
|
||
| unregister | Unregisters the specified WSL distribution | wsl –unregister Test-Ubuntu |
|
||
| help | Display information about using WSL | wsl –help |
|
||
|
||
Once you get comfortable using these switches, you’ll find that running and managing applications through WSL is much easier than managing Linux virtual machines on your own.
|
||
|
||
> *Quick tip: Discover all flags and arguments for to WSL by running `wsl --help`.*
|
||
|
||
When you’re finished, type `exit` to go back back to the PowerShell terminal.
|
||
|
||
## Sharing Windows/Linux Resources via WSL
|
||
|
||
One of the best parts of WSL is that it can seamlessly share Windows and Linux resources with each other. At this time, you can share file systems, environment variables, network resources, and command-line tools like cmd and PowerShell.
|
||
|
||
> *All examples you will see in this section are via the WSL Ubuntu Linux distro. Your mileage may vary if you’ve chosen to download a different distro.*
|
||
|
||
### Sharing File Systems
|
||
|
||
The file system is one of the most useful things to share with WSL. WSL allows you to work with both file systems as if they were one.
|
||
|
||
The Windows 10 file system is mounted as a directory in Linux while your Linux file system will be mounted as a folder in Windows.
|
||
|
||
#### Finding the Linux File System from Windows with Environment Variables
|
||
|
||
When you install a Linux distro with WSL, it will sometimes add a Windows environment variable. In the case of the WSL Ubuntu Linux distro, it will create an environment variable called *UBUNTU_HOME.* This environment variable points to the Linux */home/ubuntu* directory from both Windows and WSL Ubuntu.
|
||
|
||
The path defined in *UBUNTU_HOME* can be used to run scripts that use resources across them, or set a default location for the [Windows terminal](https://adamtheautomator.com/new-windows-terminal/ "Windows terminal") (covered later).
|
||
|
||
<img width="912" height="95" src="../../_resources/default-linux-location_017ff14ac2e9472cb260d694655.png"/>
|
||
|
||
Inspecting the WSL UBUNTU_HOME environment variable
|
||
|
||
Other distros may define a similar environment variable. Inspect the Windows environment variables with the PowerShell command `Get-ChildItem -Path $Env:\` after installing a new Linux distro to see if any may have been added.
|
||
|
||
This environment variable shortcut is handy if you want to put everything in the */home/ubuntu* directory. But let’s dig a little deeper into how it got there and how else you can reach it.
|
||
|
||
#### Finding the Linux File System from Windows via the Microsoft Store Packages Folder
|
||
|
||
Not every WSL distro is guaranteed to come with an easy way to reference it. It’s important that you learn how to find the Linux file system an alternative way.
|
||
|
||
Since most WSL Linux distributions will be installed from the Microsoft store, you can look for the Linux file system in the same place as other Windows store apps. Navigate to *%USERPROFILE%\\AppData\\Local\\Packages\* to find the directory where your Windows store apps go. Then [assume control of the folder](https://www.windowscentral.com/how-take-ownership-files-and-folders-windows-10) as this is usually protected by default.
|
||
|
||
You will see many subfolders in the packages folder where your Linux distrubution file system may be presented. The WSL Ubuntu distro, for example, was under the *CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc* folder for me.
|
||
|
||
If you navigate into the package folder, you will find the Linux file system. For WSL Ubuntu, it’s located in the *LocalState\\rootfs* folder*.* This is the root directory of your Linux distro.
|
||
|
||
|
||
|
||
Linux filesystem under %USERPROFILE%/AppData/Local/Packages/
|
||
|
||
#### Finding the Windows File System from Linux
|
||
|
||
To find the Windows 10 file system from Linux, open up WSL in Windows. WSL will then bring up a bash terminal. This bash terminal will start in your *UBUNTU_HOME* directory by default.
|
||
|
||
You can also find the root of your Windows storage volumes as well. Each of your Windows letter drives (C, D, E, etc) is treated as a mounted drive from the WSL Linux file system. You’ll find each volume mounted as */mnt/c*, */mnt/d*, etc as long as you have [root privileges](https://www.linux.com/tutorials/how-use-sudo-and-su-commands-linux-introduction/).
|
||
|
||
<img width="912" height="233" src="../../_resources/window-file-system-from-linux_860969927efd42cfa111.png"/>
|
||
|
||
Bash equivalent of running `Get-ChildItem C:\Windows\System32 | Select-Object -First 5` running on WSL
|
||
|
||
#### The WSL2 Filesystem
|
||
|
||
Navigating the WSL filesystem is fairly straightforward. Anyone not familiar with a Linux file system structure will appreciate being able to navigate it with the Windows Explorer. Bu if you want to switch to WSL2, it’s going to be a little more complicated.
|
||
|
||
WSL2 changes how everything works under the hood for sharing file systems. For starters, the filesystem is now a virtual hard disk in *vhdx* format instead of a directory.
|
||
|
||
You can find the *vhdx* file under *%USERPROFILE%\\AppData\\Local\\Packages\\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc\\LocalState* for an WSL Ubuntu distro.
|
||
|
||
You’ll find that VHDX files can be mounted in Windows with the *Disk Manager* tool. But, the virtual disks cannot be mounted while the WSL distro is registered.
|
||
|
||
### Sharing Environment Variables
|
||
|
||
Environment variables are a crucial part of any operating system, making it easy to reference binaries and executables anywhere in your applications.
|
||
|
||
Before Windows 10 build 17063, the only environment variable shared between Windows 10 and WSL Linux was the *PATH* variable. Since then it is possible to share environment variables by using *WSLENV* the environment variable.
|
||
|
||
Using the *WSLENV* environment variable to share other environment variables can feel a little meta. To share environment variables across platforms, you actually have to set environment variables inside of another environment variable.
|
||
|
||
#### Overview
|
||
|
||
Sharing environment variables is a three-step process below. The only major difference when sharing across Windows/Linux is the switch argument used (full reference below).
|
||
|
||
1. [Define environment variable in Windows](https://adamtheautomator.com/powershell-environment-variables/) or [Linux](https://linuxize.com/post/how-to-set-and-list-environment-variables-in-linux/).
|
||
2. Set the *WSLENV* environment variable equal to the previously defined environment variable followed by a switch argument (for path translation).
|
||
3. Read the environment variable in Windows or Linux.
|
||
|
||
#### Sharing Options
|
||
|
||
You can make variables available four different ways depending on which platform you’d like the environment variable to show up on using switches (table shown below).
|
||
|
||
- Windows filesystem to only be available from itself
|
||
- WSL filesystem to only be available from WSL
|
||
- WSL filesystem to be available on both WSL Linux and Windows
|
||
- Windows filesystem to be be available on both WSL Linux and Windows
|
||
|
||
| Flag | Explanation |
|
||
| --- | --- |
|
||
| /p | Single path. A variable set with this will be translated between the Windows and WSL Linux and made available to both. |
|
||
| /l | List of paths. Similar to `/p`, except it can accept more than one path. On Windows, this list will be delimited by semicolons while on WSL Linux it will be delimited by colons. |
|
||
| /u | Unix path. A path set with this flag can only be accessed when invoking WSL Linux from Windows. Can be used with either the `/p` or `/l` flags |
|
||
| /w | Windows path. A path set with this flag can only be accessed when invoking Windows from WSL Linux. Can be used with either the `/p` or `/l` flags |
|
||
|
||
#### Path Translation
|
||
|
||
The main reason to share environment variables is for path translation. As you may already know, Windows has user profile folders as Linux has user profile directories, for example. Each user has a predetermined “home folder” like *C:\\Users\\<username>* on Windows and */home/<username>* on Linux.
|
||
|
||
Using the `/p` and `/l` switches, the WSL will translate these folder paths between platforms.
|
||
|
||
#### Sharing and Translating Windows Paths with Linux
|
||
|
||
You can share a single path or multiple paths at once using the `/p` and `/l` switches.
|
||
|
||
At a Windows command prompt and with a Windows environment variable defined called *DESKTOP*, assign a value of `DESKTOP/p` to the *WSLENV* variable. This allows you to access it from WSL Linux. You can see an example below.
|
||
|
||
<img width="912" height="491" src="../../_resources/windows-environment-variables_c6dcddb3976144ab94e6.png"/>
|
||
|
||
Setting variables in Windows and accessing in Linux
|
||
|
||
The exact same procedure can be performed for multiple paths at once using the `/l` switch.
|
||
|
||
#### Sharing and Translating Linux Paths with Windows
|
||
|
||
To share and translate Linux path with Windows is the same procedure as it Windows although using [Linux-specific commands to set environment variables](https://linuxize.com/post/how-to-set-and-list-environment-variables-in-linux/).
|
||
|
||
> *For a deeper look at sharing environment variables, check out, [this Microsoft article](https://devblogs.microsoft.com/commandline/share-environment-vars-between-wsl-and-windows/).*
|
||
|
||
### Sharing Network Resources
|
||
|
||
The networking component is another handy resource to share between Windows and WSL Linux.
|
||
|
||
#### Physical vs. Virtualized Network Interfaces
|
||
|
||
In WSL2, the network interfaces are virtualized. Virtualized network interfaces mean that WSL2 network instances can hold different IP configurations than their Windows 10 counterparts.
|
||
|
||
At the time of this writing, IP addresses for WSL2 Linux use Network Address Translation (NAT) to access network resources on Windows, though Microsoft has mentioned removing NAT is high on their backlog of issues to fix.
|
||
|
||
<img width="912" height="201" src="../../_resources/wsl2-networking_d47c7a50ea394fca8b8f19430694a60b.png"/>
|
||
|
||
Same comparison from earlier, but against a WSL2 distro
|
||
|
||
#### Client DNS Resolution
|
||
|
||
WSL will still both generate */etc/resolv.conf* and */etc/hosts* files to allow for DNS resolution. As long as you don’t explicitly override that behavior in */etc/wsl.conf*, client DNS resolution will continue to work as expected.
|
||
|
||
You’ll learn more about the *wsl.conf* file later in the post.
|
||
|
||
### Using PowerShell and Bash Together
|
||
|
||
One of the coolest features of WSL is the ability to seamlessly pass information to and from PowerShell and Bash on WSL.
|
||
|
||
#### PowerShell –> Bash
|
||
|
||
Since the WSL executable accepts input from the pipeline, you can call the *wsl.exe* command inside of PowerShell and accept stdin. This allows you to use WSL to pass entire objects from PowerShell into the WSL which then get processed with the bash terminal. You can see an example below.
|
||
|
||
<img width="912" height="483" src="../../_resources/powershell-bash_355afac1255f45f5a1c5c7150b8f7c89.png"/>
|
||
|
||
Passing PowerShell to `grep`
|
||
|
||
#### Bash –> PowerShell/Cmd
|
||
|
||
You can also pass information from bash in the WSL to PowerShell and cmd just as easily. Below you can see an example of executing the Linux *ls* command and passing the output to the PowerShell `Select-Object` cmdlet via the pipeline.
|
||
|
||
<img width="912" height="483" src="../../_resources/powershell-bash-2_b32ac547dc8c48a9a1f52a62c4d1ed6f.png"/>
|
||
|
||
Passing Bash output to PowerShell
|
||
|
||
You can also call some Windows cmd utilities from the WSL and pass the output back to Linux as long as both commands are in the system path.
|
||
|
||
> *Remember that the WSL knows what the system path is on both sides because it has access to the Windows PATH variable by default*
|
||
|
||
Below you can see that you can run *[ipconfig](https://adamtheautomator.com/ipconfig-commands/ "ipconfig")*, which is a Windows command, from within the WSL and pass that output to the Linux *grep* command. You can also see the opposite of calling the Linux command *which* and passing output to the Windows *ipconfig* command.
|
||
|
||
<img width="912" height="206" src="../../_resources/batch-bash_cf8b8f3a239d4ec4aa4fd02a5bfec062.png"/>
|
||
|
||
Executing a Windows command in Linux
|
||
|
||
#### Translation Issues
|
||
|
||
There are some caveats to passing command output back and forth between bash and PowerShell.
|
||
|
||
One big problem is how PowerShell and bash return information. PowerShell is an object-oriented programming language while bash is a string manipulation tool. Any PowerShell objects piped to bash will flattened as a string. Conversely, any bash output piped to PowerShell will be converted to a string object.
|
||
|
||
You can get around the behavior somewhat by converting or explicitly casting object types in PowerShell like in the example below. But if you are expecting to pass objects between PowerShell and WSL without any extra work, you’re going to be disappointed.
|
||
|
||
<img width="912" height="491" src="../../_resources/bash-powershell-3_97eb7146015a4558b357a11a4b7f5389.png"/>
|
||
|
||
Problems passing objects
|
||
|
||
By casting the bash date as the `[datetime]` class in PowerShell, now we have a valid PowerShell object that we can use in our script. If you are writing scripts that need to go from Windows to WSL and back again, it’s possible to do with a little massaging to the code.
|
||
|
||
## Install a Windows Subsystem for Linux GUI with Xfce4
|
||
|
||
When command-line tools aren’t enough, it’s time to break out the GUIs. If you need to run a graphical utility on WSL, explore a custom distro, or you’re not familiar with bash yet, you can install a Linux GUI.
|
||
|
||
### Xfce
|
||
|
||
Linux has many available desktop environments. One of the most common ones to set up for WSL is called [Xfce](https://www.xfce.org/). At the time of this writing, Xfce is at version 4. Other desktop environments are available but in this article, you’ll learn how to get Xfce4 set up.
|
||
|
||
### xRDP
|
||
|
||
When you have a Linux desktop environment set up, you’ll need a service that understands the RDP protocol. In this article, we’ll focus on the [xRDP server](http://xrdp.org/). xRDP is an open source RDP server for Linux that allows you to use RDP clients to connect to Linux just as if you can Windows hosts.
|
||
|
||
### Setting Up
|
||
|
||
To access a Linux GUI from Windows with Xfce4 and xRDP, follow the instructions below. In a WSL terminal:
|
||
|
||
1. **Download and install Xfce4 –** Download and install Xfce4 using the command `sudo apt-get -y install xfce4 && sudo apt-get -y install xubuntu-desktop`. This will take a while. Stand by.
|
||
2. **Install the xRDP server –** Download and install xRDP by running `sudo apt-get -y install xrdp`.
|
||
3. **Configure xRDP for xfce4 –** `echo xfce4-session > ~/.xsession`
|
||
4. **Restart xRDP** – `sudo service xrdp restart`
|
||
5. **Find the WSL distro IP address** – `ifconfig | grep inet`
|
||
|
||
At this point, you should be able to open an RDP session from Windows 10. Open up remote desktop connection window using `mstsc` and provide the Linux IP address found in step #5.
|
||
|
||
If all goes well, you can open an RDP connection to the Linux distro that’s running on your Windows operating system as shown below.
|
||
|
||
<img width="912" height="733" src="../../_resources/windows-subsystem-linux-gui_96f06e39c856495285d3eb.png"/>
|
||
|
||
Windows Subsystem for Linux GUI with Xfce4 and xRDP
|
||
|
||
## Tips and Tricks
|
||
|
||
Now that you know the basics of WSL and how to use it, what’s next? Fortunately there are a lot of tools that are either built for or work well with WSL.
|
||
|
||
### Setting WSL Configuration Items at Bootup with *wsl.conf*
|
||
|
||
A configuration file exists in the WSL at */etc/wsl.conf.* This file contains configuration settings that run every time the WSL distro is started. When the *wsl.conf* file exists*,* WSL will ingest any setting in this file every time the Linux distro is started.
|
||
|
||
There are a few different sections inside of the *wsl.conf* file you can configure.
|
||
|
||
- **Automount** – Mounting drives from Windows at start
|
||
- **Network** – Generate *resolv.conf* or the *hosts* file
|
||
- **Interop** – Enabling or disabling interop with Windows
|
||
|
||
For more details on the *wsl.conf* file*,* check out the [Microsoft *Set WSL Launch Settings*](https://docs.microsoft.com/en-us/windows/wsl/wsl-config#set-wsl-launch-settings) page.
|
||
|
||
### Developing on WSL with Visual Studio Code (VS Code)
|
||
|
||
VS Code seemingly integrates with everything and WSL is no exception. From within VS Code, you can set up a workspace on your WSL Distro but manipulate it completely with VS Code on Windows. You don’t even need to have a terminal running!
|
||
|
||
To set up VS Code on Windows to work with WSL, you’ll first obviously need [VS Code for Windows](https://code.visualstudio.com/download) installed. Also be sure you have the [*Remote – WSL* VS Code extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl) installed.
|
||
|
||
Once you’ve got the extension installed, you can now connect to it by opening a WSL terminal and running `code <workspace>`. `<Workspace>` is the directory where you’d like to run VS Code from. VS Code will then detect that you are in a WSL distro, open a window, and establish a connection to to the workspace.
|
||
|
||
Confirm it worked by noticing the WSL connection icon in the lower left corner of VS Code. You should see that it has the name of your WSL distro.
|
||
|
||
<img width="912" height="684" src="../../_resources/visual-studio-code-wsl-2_d164c58c593b4e2a93758914e.png"/>
|
||
|
||
Working with WSL and Visual Studio Code
|
||
|
||
You can even use the built-in terminal to interact directly with the WSL workspace. There’s no need to run a separate window for [git bash](https://git-scm.com/downloads) commands.
|
||
|
||
### Adding Windows Subsystem for Linux to the Windows Terminal
|
||
|
||
Another useful use-case of WSL is to add the WSL console it to the [Windows Terminal](https://github.com/microsoft/terminal).
|
||
|
||
From within Windows Terminal, you add each WSL distro in it’s own tab. You can also customize the look of each tab so you don’t get lost.
|
||
|
||
If you’re using a WSL distro that sets an environment variable for the user directory like *UBUNTU_HOME*, you can also set that as the starting directory for your terminal.
|
||
|
||
<img width="912" height="590" src="../../_resources/terminal-1_6ef7482e07e24f7fafbfad1e09ca1824.gif"/>
|
||
|
||
Checking the date in PowerShell and Bash
|
||
|
||
If you’d like a complete video walkthrough on setting up WSL to work with the Windows Terminal, check out the TechSnips how-to video below.
|
||
|
||
## Closing Thoughts
|
||
|
||
Microsoft released the WSL to allow Linux developers the ability to develop on Windows. So far, the WSL has been a step in the right direction.
|
||
|
||
It appears that the WSL is going to be a crucial component of Microsoft’s new open-source friendly strategy. If Microsoft is going to take on Apple to be the devices that developers write their code on, it’s going to be an uphill battle. But WSL is a strong card to play.
|
||
|
||
WSL brings about many many welcome benefits to developers like:
|
||
|
||
- Significantly lighter weight than running local Linux VMs
|
||
- Removing the overhead of installing and managing a hypervisor
|
||
- No more requirement for multi-partitioned hard drives
|
||
- No more complicated grub bootloaders
|
||
|
||
WSL just turns on and runs so we can all code happily ever after. |