Better Windows Development Workflow with WSL
Part 2: Additional Setup

By codeitadmin April 3, 2018 • Posted in: Automation, Linux, Windows Development, WSL

Now that we have a working bash prompt, you’ll see that we need to tweak a couple of things to make it as seamless as possible. First, we want to make sure that our project directories are accessible. And second, we want to setup a bin and edit our .bashrc file to read from it, so we can create some shortcuts for a smoother workflow.

Making files accessible

The Linux files inside your distribution contain metadata which is treated differently than files created by Windows. For this reason you are, by design, unable to edit those files using windows tools. Let’s look at an example. From Powershell open a bash prompt
ps C:\Users\USERNAME > bash
from there let’s create a file in our home directory, and populate it with some test data
# cd into your home directory
User@HostMachin:/mnt/c/Users/<Your User Name>$ cd ~

# create a test file
User@HostMachine:~$ touch test.txt

# add some text to the file
User@HostMachine:~$ echo 'Test text' > test.txt

# Open the file in nano so we can see that the text has been written
User@HostMachine:~$ nano text.txt
We see here that the file has been written to
Fig 3: Nano editor with test text
Now, Nano is great for quick edits and is absolutely worth learning, but for most things I do in my day to day work, it just isn’t super practica, mostly because I don’t know it as well as I should. Becoming more proficient with it is on my roadmap, but what I really want to do is use my editor of choice, currently VS Code. So let’s try it. Press ctrl+x to close nano and return to the bash prompt. Now try to open test.txt with VS Code Note: This assumes that you have VSCode added to your system path, and can normally access it from Powershell by typing “code” if that is not the case, see this stack overflow answer for details on how to fix it So we now try
User@HostMachine:~$ code text.txt
But what we get is an empty document. What the hell happened? Well it turns out that this is by design, and is to keep you from breaking something. The files included in your Linux distribution contain some additional metadata that Windows doesn’t work with, and altering these files can result in a broken Linux installation. Okay? So now were in the same boat we started in right? We have to use two sets of tools to work on our files. One set for Windows, and another for our php/python/ruby/sh/whatever files. Now, it should be noted at this point that we are free to work on our Windows files using Linux tools all day long. That is incredibly useful, and if that is all you want to us WSL for you are good to go. But… What I ultimately wanted was an environment where I could do all of the following.
  1. Get a running Lamp stack to use as a local development server.
  2. Have a working bin directory that would allow me write scripts to automate things like creation of V hosts, installation of WP and other CMS systems and all of the other tedious shit that prevents me from doing what I really want to do. Write code.
  3. Be able to use all the design tools I need, without switching machines or running a VM
  4. Be able to use my editor and existing project directories
  5. Not buy a Mac. OSX allows for all of this out of the box, but I like being able to upgrade my hardware, and do custom builds.
What we need to do now is find a way to let us work on files within the Linux file system using our Windows editor of choice, in this case VS Code… Symlinks to the rescue Turns out that trick is to make it such that Linux opens our files, but they are still part of the Windows file system. For that we need a symlink
In computing, a symbolic link (also symlink or soft link) is a term for any file that contains a reference to another file or directory in the form of an absolute or relative path and that affects pathname resolution.

Creating a Bin Folder For Scripts

For this example, I am going to create a script bin on my local drive, and then create a symlink within my home directory. The WSL installation sees your files system as a mounted file system, and you can access it like this from Bash:
User@Host~$ cd /mnt/c/path/to/your/folder
So to create a folder, and then create a symlink you can do it like this
# Create a directory in the host file system
# you will need to do this with elevated permisions in bash using the 
# sudo keyword
User@Host~$ sudo mkdir /mnt/c/scriptbin

# and then create your symlink using the ln keyword like this:
User@Host~$ sudo ln -s /mnt/c/scriptbin ~/bin
Now, you should have a symlink in your home directory with name bin. Check by typing
User@Host~$ ls ~
Finally, let’s make sure it’s readable and writable by our editor
# create a test file && write some data to it
User@Host~$ touch ~/bin/test.txt && echo 'Test Text' > ~/bin/test.txt

#open the file in nano to verify the write
User@Host~$ nano ~/bin/test.txt
You should see ‘Test Text’ in the resulting nano screen, press ctrl+x to close. Now for the trick. Let’s try opening that file with VS Code on our host system
User@Host~$ code ~/bin/test.txt
It works! Now let’s use it to do something useful. This is a small script to download the newest version of wordpress, unpack it into the current working directory move the files out of the wordpress directory, and remove the installation files.
# First, let's delete the test.txt file using the rm keyword
User@Host~$ rm test.txt

#now let's create a new file wpsetup and open it it vs code using the && (and) operator
User@Host~$ touch wpsetup && code wpsetup
This should open a blank file in code named wpsetup. Copy/Paste the below script into the new file and save your changes
#! /bin/bash

# the /bin/bash on the first line tells bash to run 
# this file as a bash script, regardless of extension. 
# You can do this with most any installed scripting language

# use wget to download the tar.gz file

# then extract the file  
tar xfz latest.tar.gz

# then move all files from wordpress to current directory
mv wordpress/* ./ 

# then remove the empty wordpress directory
rmdir ./wordpress/

#finally remove the tar.gz file
rm -f latest.tar.gz
Now we need to make the file executable. Go back to your bash prompt, and enter the following Note: You will always have to make these scripts executable for the next steps to work
# chmod signals that we are changing permissions
# +x signifies that we are adding executable to current permissions
# finally wpsetup is the name of the file we are effecting 

chmod +x wpsetup

Adding your new bin directory to .bashrc

the last step we need to take is to add the newly created bin directory to .bashrc. .bashrc is a file located in your home directory that tells bash how to behave. .bashrc is extremely powerful, and there many things you can do with it, including changine your prompt colors, creating aliases to run scripts with simple commands, and loads more that we will look in later parts of this series. For now, don’t make any other changes to your .bashrc file unless you know what you are doing. the first thing we want to do is open .bashrc using the nano editor. Do not attempt to modify this using code .bashrc is part of your home directory, and was not created with a symlink, so your windows editor will not work correctly with it.
User@Host~$ nano ~/.bashrc
With the file open in nano scroll all the way to the end of the file by pressing alt+/ paste the following lines into the file making sure that all three lines paste correctly onto a new line
if [ -d "$HOME/bin" ] ; then
    export PATH="$HOME/bin:$PATH"
Save the file by pressing ctrl+o exit nano with ctrl+x finally, restart bash by typing
User@Host~$ exec bash
Now we should be able to use our new wpsetup script. go to a new directory where you comfortable installing wordpress. For me, I keep my projects directory in /c/www, yours will vary. in the bash terminal enter
cd /mnt/c/<your-project-directory>
substituting the path you want to use in place of your-project-directory, then run your script
User@Host /mnt/c/<your-project-directory>$ wpsetup
The script should fetch the installation files, unzip, and cleanup after itself. Saving you from having to manually install each time. This is the true power of having access to these tools. It may not seem like a huge deal at a glance, but imagine a scenario where you need to do this multiple times in a week. Now imagine having scripts that can not only download and extract WordPress, but one that can create the directories, users, databases and run the installer completely autonomously! Note: you probably wouldn’t want to build such a script, as there is a super awesome command line tool for wordpress, wp-cli that does all of that and more and works very well as part of a bash script. In the next guide we’ll look at how to setup lamp-server, so you can have a locally running LAMP stack on your local machine, complete with scripts to automate the creation of vhosts, and plenty of other fun stuff.


add comment

Your comment will be revised by the site if needed.