BoUoW: Bash on Ubuntu on Windows

Tux is telling you the most current Ubuntu running for Windows for BoUoW.

I am not proud of possibly inventing the ugly acronym “BOUOW”, but “BASH on Ubuntu on Windows” appears to compel it. Maybe we can pronounce it “bow-wow” — not sure if that’s complementary. Just did a Google search, and, no, as predicted I couldn’t have invented it: It is variously acronymed: B.O.U.O.W., or BoUoW. It has been around since at least March of 2016, giving end users, computer geeks, and developers plenty of time to come up with something of a nickname or acronym.

But I actually mean to praise BoUoW, and to give it considerably high praise. This is a brave move on Microsoft’s part, and a long time coming. MS has made *NIX access available in its kernel for some time now, thus making *NIX conventions possible on the command line like certain commands in the Power Shell. The user has to enable the capability in the Windows 10 settings (“Windows Subsystem for Linux” (WSL)), and as Admin, the kernel has to be set to “Developer mode”, and follow the instructions on the MSDN website to download binaries and to enable a bash shell on either the command line or PowerShell.

BoUoW takes advantage of the WSL to do impressive things like use the same network stack as Windows 10 itself. This is because with WSL enabled, a UNIX command such as SSH can now make calls directly to the Windows 10 kernel to access the network stack.

This is, by Microsoft’s admission, a work in progress. It would worry me if they would not have said that. But lots of things do work. vi works and is symlinked (or somehow aliased) to vim. The bash shell comes with some other common aliases like “ll” for “ls -l”, for instance, and apparently, as part of the installation, you actually have a miniature version of Ubuntu, complete with a C compiler, and an image of Ruby, Perl, Python, and if it isn’t installed, you can always use “apt-get” to install it.

One of the security features has the disadvantage of conducting an install of BoUoW separately for each user. If a user types “bash” in a cmd window, and if BoUoW is not installed for that user, the install happens all over again, and the image goes under each user’s AppData directory requesting a BoUoW install. If you are using an SSD for C: drive like me, then you might find that limiting due to a shortage of space.

There are many things not recommended yet. If you are a serious web developer, for example, you would find many of the things you want, such as mySQL, are not currently working the right way. If you are a systems programmer, then you’ll find that ps and top only work for unix-like commands, so I wouldn’t use BoUoW for any serious process management. That being said, it does contain the old standbys: grep, sed, and awk.

The compiling and output of my “Hello, world!” program, also showing the source code.

gcc had to be installed separately. The binary it created for my “Hello, world!” program lacks the Microsoft .exe extension. And as it is for Unix binaries, it lacks any default extension. It is using gcc version 4.8.4. The current version is 6.3. This older gcc usually won’t pose a problem for most users.

The current stable Ubuntu is 16.04. BoUoW uses the previous stable version, 14.04, and thus has slightly older versions of Perl (5.18), Python (2.7.6), bash (4.3.11), Ruby (1.8) (available using apt-get), vim (7.4), and other software. Vim, however, appears to be the “large” version, which is expandable, using plugins like Vundle, which is good news. I don’t suspect that these slightly older versions would cause anyone problems, except possibly for Python, which has gone all the way up to version 3.5.2 since. You are warned also that it is possible that under Python or Perl, you might run into problems due to not all of their libraries running correctly under BoUoW. Not surprising, since Python has hundreds of installable libraries and Perl has thousands of them. Could take a while.


… being a vi/vim purist ….

I had set up and edited websites using traditional vi with only the mappings and settings I placed. Mostly, but for a few lines in my .virc, .elvisrc, or .vimrc file, I was happy with the default settings of traditional vi that I needed few mappings, and anything I wanted to do in a single keystroke that needed mapping I would just map the key as I was editing. This meant I could get along with any vi version, even the stripped-down BSD vi editor that is the default at my ISP. I’ve never complained about their editor. I could always set things up in a way that worked around whatever limitations of the editor I was using.  I could rely on the fact that all vi versions had basic key mappings that were common, and characteristic of vi in general. In addition, all vi clones had the ability to map keys to user commands using “:map”.

I was mostly an Elvis fan (the vi clone, not the singer), since it was pretty “souped up” while not having settings that slowed it down or interfered with existing default key mappings. For a while, my .elvisrc had some key mappings I wanted, and had the ability to map key combos during insert mode. Elvis had a help system, based on HTML, with links to other files in the help system. Elvis could navigate HTML, and more. The Elvis project was abandoned for some years, but seems to have been revived around last year, and there is currently some activity in the GIT repository regarding Elvis. I hope people see value in it, since it was a pretty decent editor.

vim (short for “vi improved”) has been around for, I think, more than a decade, and has caught on to the point that it appears to be the de facto vi most developers use. It has coexisted with Linux, and in most Linux distros, it appears to be the default vi used. Ever since the mid-90s when I began using Linux, I had made, as one of my adjustments to the default installation, an uninstall of vim, and an install of Elvis in its place.

Then, I went on ITunes, and downloaded material from a Harvard Open Course called CS 50, and learned that vim had, for many years, a number of plugins and other weird stuff I had not seen in vi before.  I was shown in a video how graceful and skilled the demostrator was in using these plugins (although most of his commands could be replaced with traditional vi commands with the same number or fewer keystrokes), and a killer text interface that got me interested. The installation commands I was to use to begin my journey was:

> cd ~
> git clone
> ln –s dotfiles/.vim* .
> git clone .vim/bundle/vundle
> vim +BundleInstall +qall

While there were some great improvements to the interface, some of the packages introduced a slew of key mappings which clobbered a lot of default mappings with new ones. CTRL+B (originally the command to move backward 15 or so lines) became something which opened new colon command lines (even multiple colon command lines). Some aspects of the new vim dotfiles also greatly slowed down the program, as well as imparting strange behaviour when the program is first called with a filename. That would include quickly jumping around crazily and making random text inserts. This was observed in Linux as well as Cygwin. The only choice then was to issue a :q! command and leave the file un-edited. In case you were wondering, “vi -r” was not used, although it appeared as though vim was performing a recovery on a file that needed no recovery, resulting in a mess.

It would appear that the plugins are great for new users so long as you don’t know any vi commands. That way, you don’t have to hack your way through the config files like I have to in order to coax more traditional behaviour while taking advantage of its many good points.  One of them being the ability to use multiple windows on the same interface. Most of the new keystroke command mappings do not seem like improvements to me, after all, a keystroke is a keystroke. But a new user would not be troubled by it, since there are no prior habits to unlearn. Although, if a new vim user moves to a system which uses traditional vi, he or she will find trouble.