My experience with Windows Subsystem for Linux thus far

I just added to the knowledge base by providing some information on using aliases in Windows Subsystem for Linux (WSL) here. That document was in part inspired by my experience playing with Jekyll (a “package” for the Ruby programming language) to setup a website. Jekyll is a slightly friendlier way of making a static website (as opposed to one that has connections to databases and things like that) for things like blogs, but allows one to do most of the text editing via markdown, instead of pure html. In this respect, like Rmarkdown and knitr, Jekyll serves as a nice intermediate between being a normal(ish) person and a full-on web developer, while still allowing one to make a decent looking website. It also turns out that Jekyll (and its many pre-made themes) are used to back-end a lot of GitHub Pages, including integration with commercial web services, such as Netlify. For more on using Jekyll to quickly make a GitHub Pages website: http://jmcglone.com/guides/github-pages/.

My website is still under development (a semi-working copy of the site is on GitHub Pages: https://wetlandscapes.github.io/blog/), but I started with a Windows-based version of Ruby and Jekyll. After using the Windows environment for a while, I thought it would be kind of interesting to use WSL so I could start getting better with Linux commands (including git), since Ruby is really more of a Linux/UNIX tool. Below are some of the issues I ran into while trying to get my Linux workflow in-line with a comparable Windows workflow.

Pasting text into WSL’s shell

My first challenge was figuring out how to paste into the WSL shell. I’m used to [Ctrl]+[c] and [Ctrl]+[v] for copying and pasting. Copying works in the same way as it normally does (select and copy), but pasting is a little different in WSL. To paste in WSL you have to [right-click] your mouse with the cursor where you intend to copy the information. There’s probably a really good reason for this deviation in protocol, but I don’t know what it is. So, just be aware.

File systems between Windows and Linux

Another challenge was understanding the relationship between the Linux and Windows file path conventions. Turns out that I can access any of my Windows drives as mounts and then access the folders and files as normal. So, for example, the folder C:\RWorkspace\CodeSnippets (for Windows) is the same thing as is /mnt/c/RWorkspace/CodeSnippets (for Linux).

Installing packages/programs/applications in WSL

I ran into an issues with downloading updates and packages in WSL (e.g., sudo apt-get update) because my anti-virus program (Kaspersky) didn’t trust the web address. There seems to be a work around for this issue (see this forum post for a work-around specific to Kaspersky), but I literally just disabled my anti-virus during the downloads and then re-enabled it after. Probably not the smartest way to do things, but it worked.

Environmental and PATH variables

My last challenge was some PATH confusion for WSL vs Windows. This issue really goes beyond my understanding of computer operating systems, but I’ll do my best to try and explain what happened and how I resolved it. Basically, I had a Windows version of Ruby and I was trying to run Ruby/Jekyll commands from WSL, but kept getting an error. Shell was telling me that WSL couldn’t find Ruby, even though it was pointing to the correct installation location (for Windows). I tried doing lots of things to work around this, including editing the PATHs in my Windows environment (probably shouldn’t do that directly unless you really know what you’re doing), but it was a no-go. So what I ended up doing was uninstalling Ruby for Windows and instead installing it via WSL/Linux. I tried having both a Windows and Linux version, but because of the PATH issues, I couldn’t seem to get WSL to recognized the Linux version of the program until the Windows version was uninstalled and its PATH variable removed from Windows.

What this suggests to me is that if you have the same program installed in both Windows and Linux, you may run into issues, at least with some programs that need their PATH’s explicitly added to Windows' environmental variables. Not sure how big a deal this is going to be, but separating programs by operating system is fine for now, considering the convenience of WSL.