How to channel your inner penguin on Windows 10 with Linux

Are you an avid Windows user who is curious about software development on Linux? Have you recently switched from a Mac and feel lost in a Windows ecosystem? In this post, I’ll touch on a few ways to transition into Linux with Windows Subsystem for Linux (WSL).


Everyone’s A Critic

I’ve heard from both Linux and Mac users that Windows operating systems aren’t always conducive for the type of work they do. From the perspective of someone who uses Windows daily, why would that matter? There are a lot of programming languages that Windows supports. Languages like Java, C++, C#, Visual Basic .NET, and JavaScript seem to be among the most popular. To further reinforce this point, metrics like the TIOBE Index,  PYPL Index, and GitHub’s Octoverse report, show the same year-over-year trends relative to popularity. So what seems to be the problem?

The way I see it, there are a few possibilities for this trend. Software developers using Windows could be blissfully unaware of what they are missing on Linux. The barrier for entry on a Windows machine might be lower because you’re not forced into buying a Mac or building your own rig to support Linux. The vendor lock-in and tooling prevent developers from making the switch to Windows from a Mac.

None of those possibilities explains everything. For instance, documentation and tooling can be a challenge with Windows. I’ve read through plenty of programming tutorials, only to find examples for Mac and Linux. Sometimes examples for Windows are outdated or are only available as a workaround. Even when there are examples provided, tooling and language support isn’t up to par. If so many people use Windows, then why do situations like this crop up?

Ruby on Rails is a prime example of what I’m talking about. Ruby as a language makes sense to me. I like that I can use the Rails framework to quickly build a website and count on things working. I like that even in the event that my code doesn’t work on the first try, I can debug my way to a solution through helpful error messages. On Windows, developing in Ruby hasn’t been awful provided your web app matches the Rails stack available for download. Even so, it still lacks the configuration and support of its *nix counterparts.

ruby_rails_versions

This photo isn’t meant to be a disparaging finger wag. I realize that people have much better things to do than cater to my every need. What I’m trying to highlight, is that at least on Windows, this is the suggested way to install Ruby and the Rails framework. With this method, managing dependencies for your Rails projects is a nightmare. If you have specific versions of Ruby that you need, you’re stuck finding a verified download. If you have to use an external framework like Node, then you’ll wind up finding the installation that includes all of its dependencies. If you want Postgres instead of SQLite, it’s on you to manage the install. You can really feel the pain of not having a package manager in these situations.

While Rails is only one framework, it does identify some core issues. The developer experience outlined above might explain why *nix users haven’t lined up in droves to use Windows as their daily driver. A lack of first-class support for more programming languages as well as missing CLI tooling can leave a lot to be desired. There are more programming languages out there other than C# and Java right? Well obviously yes. As a guy who gets paid to develop in .NET and likes to experiment with other languages, I was surprised with the following scenario.


Microsoft Is Changing

The year is 2019. Microsoft has invested time and talent into open source collaborations. Visual Studio is now available as a cross-platform offering. The .NET runtime can be deployed, compiled, and hosted on Linux servers. Linux distributions have been given native support on Windows 10 machines. You can create virtual desktops and save multiple items on a shareable clipboard. The search assistant can now look through your local apps, documents, email, and web. The screen snip app allows you to capture and edit images, which can be saved to your clipboard. There are new viable package managers available for keeping your dependencies in line. Homebrew even recently announced its support with a WSL integration.

Well, I’ll be. This is a huge departure from the proprietary software wielding company that once was. Clearly, people and organizations are pairing up with Microsoft to work on Linux integrations. So, what is the best way to use Linux on Windows 10?


Enter WSL

WSL is an awesome tool that primarily benefits two types of developers. Folks that prefer the command line and use an editor in the terminal make up the first group. The second is text editor lovers looking for a better terminal experience in Windows. According to the WSL documentation,

“The Windows Subsystem for Linux lets developers run GNU/Linux environment – including most command-line tools, utilities, and applications – directly on Windows, unmodified, without the overhead of a virtual machine.”

Awesome right? You’ll be able to run Linux natively inside Windows 10. In fact, you aren’t even tied down to having to use a single flavor of Linux. You can have multiple Linux distributions installed and can use them for their strengths as you see fit. Sharing computing resources to fuel a virtual machine is now a thing of the past.

How does this all work? Technically WSL is not a Bash shell or a terminal emulator. WSL is an application that translates Linux system calls into Windows system calls. Another way to think about it is that the Linux kernel is exposed on the Windows kernel. You can traverse the Linux and Windows filesystems from a Linux environment. Familiar commands like grep, awk, and sed are now options for you to use. First-class support for programming languages such as Ruby, Python, Rust, or Go are now available. 


Installation

To install WSL, check out the documentation from Microsoft. You’ll also need to pick which distribution(s) to download from the Microsoft Store.

microsoft_store_linux

I like Ubuntu, so that’s what I chose for myself. During the installation process, you create a user account for that specific distribution. The new Linux user account is not tied to your windows user account. Each user account you create will be able to use the sudo command to elevate a process.

Running WSL will start a Bash shell inside the default Console Windows Host. The problem I had after my first installation, was that the terminal configuration. It had a black background, dark blue text, and neon green directory colors. As someone that uses reading glasses, this made it painfully difficult to read.

Is there a fix for that? Absolutely. If you have more time and patience than me then you might like ColorTool. This allows you to change the default color scheme on the default Windows Console. I chose to use a different terminal called WSLtty. I liked the support for 256 colors, mintty themes, clipboard, fonts, and small program size. WSLtty is just mintty (a terminal emulator for Cygwin), but for WSL. It uses wslbridge which, 

”…allows connecting to the WSL command-line environment over TCP sockets, as with ssh, but without the overhead of configuring an SSH server.”

I chose to download and install WSLtty as a standalone installer. I found that the installer takes care of setting your environment path variables. It also allows you to run two shortcuts that it adds to your start menu. The first is “WSL Terminal %”, which will open up WSLtty in

/mnt/c/Users/<windows username>

The second shortcut is “WSL Terminal” which opens up WSLtty in “~” aka

/home/<linux username>

The two other installation methods I tried were Chocolatey Nuget and Scoop. I had luck with Chocolatey. Scoop didn’t play nicely with my machine. Other people might have a different experience, but the install failed for me twice.


Configure Your Terminal

With WSLtty installed, you are going to want to change some of the default settings to make it look the way you want. With a WSLtty terminal open, you can right-click anywhere in the title bar to access the options. This will open a separate window which gives you many ways to configure your terminal window.

wsltty_config_options

If you’d like an example, you can use my personal configuration. There are some default themes already loaded for the terminal itself. None of these were to my liking. After doing research on the web and through some trial and error, I was able to find some themes that work well for me. If you want some suggestions you can see the themes I’ve downloaded. Otherwise, I found http://terminal.sexy/ to be very helpful for previewing themes. It allows you to export a selected theme in a MinTTY theme format.

neofetch

Now, cloning these config files and themes is one thing. Knowing where to put them so that your WSLtty terminal can use them is another. In Windows, it can be downright confusing to find out where an application got installed. Additionally, the settings or configuration files aren’t always visible. Some software installations intentionally keep its contents hidden to avoid user tampering. Before you can do anything, you’ll need to make sure that you can see hidden files in your folders. To do this you can open the file explorer, go to the view option in the toolbar, and find the checkbox for hidden items. While you’re in the view, I’d also recommend enabling file name extensions. It will make your life much easier.

hidden_files

At this point, you should be able to navigate to the wsltty directory. To get there you will have to navigate to the path outlined in the %appdata% environment variable. %appdata% when entered into the file explorer’s address bar will take you to

C:\Users\<windows username>\AppData\Roaming

Application data, aka AppData, is stored across three subfolders. The one we care about is Roaming. You can copy your themes into the themes folder. If you have language packs or compatible sounds for WSLtty, the folders are there as well.

If you want to add more fonts to your terminal, you can download True Type Font files (.ttf) from anywhere. As an example, I downloaded a few fonts from Powerline Fonts. You can save the fonts in a zipped folder, extract the contents, and install individual fonts. All you have to do is double click the .ttf file and it will prompt you to install the font. If you have buyers remorse after installing a font, you can navigate to

C:\Windows\Fonts\

to remove a font.


Editor Configuration

It’s great to have an aesthetically pleasing terminal since odds are you’ll be looking at it all day. But being able to be productive with an editor is undoubtedly more important. As a Vim user, the focus is always on making the editor conform to your needs. I know people who have spent years getting their Vim editor looking and performing the way they want it to. Lucky for you, you can copy your configurations into your new Linux distribution and be off to the races. There are still a few hiccups here and there given that WSL is so new, but I haven’t found it to be a problem. Emacs users, I’m sorry. For graphical interfaces, you’ll need an X Server for Windows and that’s more than I care to get into right now.

If Vim isn’t your thing and you’d prefer to use a text editor but with a better terminal, then you have that option too. Using Visual Studio Code as an example, you can alter your settings.json file to look something like this

{
    "terminal.integrated.shell.windows": "C:\\Windows\\sysnative\\bash.exe"
}

This will open up Bash.exe within a window inside the editor.

What if you’ve put a lot of time into configuring a nice looking terminal? You should be able to use it instead of the default Bash terminal right? Not exactly. To get your shell to work in Visual Studio Code, you need to locate the correct executable file. The exception to this rule is that the shell executable must be a console application. The reason is that stdin, stdout, and stderr need to be redirected.

So, will you be able to get a terminal emulator like WSLtty working inside Visual Studio Code? Unfortunately no. WSLtty isn’t a shell, and it doesn’t have a single executable file. Using the mintty.exe won’t be enough since it uses wslbridge as a dependency. To get WSLtty working from in Visual Studio Code, you can alter your setting.json to look something like this

{
"terminal.integrated.shell.windows": "C:\\Users\\<usrname>\\AppData\\Local\\wsltty\\bin\\mintty.exe",
"terminal.integrated.cwd": "C:\\",
"terminal.integrated.shellArgs.windows": "-i C:\\Users\\<username>\\AppData\\Local\\wsltty\\wsl.ico --WSL= --configdir=C:\\Users\\<username>\\AppData\\Roaming\\wsltty\"
}

This will open a separate WSLtty terminal starting in the C: drive with the penguin icon and your applied WSLtty configurations.


Avoid Corrupting Your Distro

At this point, I’d recommend you DON’T explore the Linux filesystem if you’re using any Windows apps. This is a fantastic way to wind up knees to face, crying yourself to sleep because you’ve corrupted your Linux distribution. Amongst other things, Windows CR LF line endings and file metadata are not handled in Linux. Windows apps can apply a read-lock on a file, preventing any updates to its contents.

Make smart choices, and don’t let your curiosity get the better of you. A general rule I follow is to stick to one filesystem or the other. If you are more comfortable navigating the windows filesystem, then you might consider sticking with

/mnt/c/*

I use a folder called Code in

C:\Users\<windows user>

which houses all my projects. When I’m in Linux, I do my work in

/home/<username>/

Regardless of what you do, you should consider saving your dotfiles in a distributed version control system like GitHub. I’ve fubar’d my Linux distributions enough times to make this necessary for myself.

If you found this post helpful or have other helpful tips for WSL, please feel free to leave a comment below!

Avatar
Mitchell Volk
Senior Business Intelligence Developer

I’m a data enthusiast with a flair for visualization.

comments powered by Disqus