Bash on Ubuntu on Windows: What Shell People Should Know

If your day runs through a terminal, a Windows machine has usually meant some kind of workaround: a Linux virtual machine in a window, a pile of ported tools that almost behave like the real ones, or just a second computer. At Build on March 30, Microsoft showed something different, and last week the first public version landed for Windows Insiders. It’s called Bash on Ubuntu on Windows, and the plumbing underneath has its own name, the Windows Subsystem for Linux. I want to lay out what Microsoft and Canonical have actually said about it, because the name invites a lot of guessing.

What they say it is

Mike Harsh’s announcement on the Windows Developer blog describes new infrastructure built into Windows, the Windows Subsystem for Linux (WSL), on top of which Windows runs a genuine Ubuntu user-mode image provided by Canonical. The point is to run Bash scripts and Linux command line tools like sed, awk and grep, plus Linux-first tools like Ruby, Git and Python, directly on Windows. The WSL docs published for the Insider release say the same thing more plainly: the command line utilities are the same ones that run in a native Ubuntu environment.

Canonical’s Dustin Kirkland, who worked on the project, wrote the Ubuntu side of the announcement and spent most of it on what this is not. It isn’t a virtual machine, and there’s no Linux kernel booting under a hypervisor. It isn’t a container. It isn’t like Cygwin, where open source tools are recompiled from source for Windows. These are unmodified Ubuntu ELF binaries, identical bit for bit, running directly on Windows. The closest comparison he offers is a Linux emulator: Microsoft adapted some of its research technology to translate Linux system calls into Windows system calls in real time, which he describes as roughly the inverse of Wine. He also notes the subsystem isn’t open source at this time, and that the image was Ubuntu 14.04 LTS, with 16.04 expected to replace it soon.

The docs’ FAQ gives the practical reason to care. WSL needs less CPU, memory and storage than a full virtual machine, and your Linux tools run alongside your Windows apps against the same files.

What it isn’t meant for

Microsoft was unusually direct about scope. Harsh calls it a developer toolset for writing and building code, and says it isn’t a server platform for hosting websites or running server infrastructure. For production Ubuntu workloads he points to Azure, Hyper-V and Docker. The PowerShell team’s post, Bash for Windows: Why it’s awesome and what it means for PowerShell, repeats that it isn’t for running or hosting production Linux workloads, and that Bash and PowerShell simply sit side by side.

The WSL FAQ as of this week adds more boundaries. WSL doesn’t aim to support GUI desktops or applications such as GNOME or KDE. You can run many popular server applications, Redis being the example it gives, but Microsoft doesn’t recommend WSL for server scenarios. Ubuntu is the only distro for now. It’s x64 only, and it’s coming to desktop versions of Windows, not Server SKUs. Harsh’s post also says Bash and Linux tools can’t interact with Windows applications and vice versa, so you can’t launch Notepad from Bash or run Ruby in Bash from PowerShell.

Who can try it, and how

The first public release shipped in Windows 10 Insider Preview Build 14316, which went out to the Fast ring on April 6. So you need to be a Windows Insider on the Fast ring, on build 14316 or later, and Rich Turner’s install post on the command line team blog stresses that you need a 64-bit version of Windows 10 on a 64-bit PC. If Windows Subsystem for Linux doesn’t show up in the optional features list, he says you’re probably on 32-bit Windows or an older build.

The setup is short. Turn on Developer Mode under Settings, Update & Security, For developers. Then open Turn Windows features on or off, check Windows Subsystem for Linux (Beta), click OK and reboot, which Turner says is required. After the reboot, open a command prompt or PowerShell, run bash, accept Canonical’s license, and it downloads the Ubuntu image and adds a Bash on Ubuntu on Windows shortcut to the Start menu. The installation guide also gives a PowerShell way to enable the feature from an elevated prompt:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

If you break something and want a clean start, Kirkland’s HOWTO on the Ubuntu blog and the WSL command reference both point to lxrun, which removes the Ubuntu image, with the full switch taking your Linux home directory too. Run bash again afterward to reinstall.

lxrun /uninstall /full

There’s one detail in Turner’s release notes that matters if you care about permissions. In this build Bash runs as the Linux root user, but that doesn’t give Bash elevated rights in Windows unless you start it as Administrator, so by default you can only reach the Windows files your own account can. Microsoft says future builds will ask you to create a user account at install time and let you use sudo within Linux.

How files and paths are shared

This is the part that decides whether it fits your workflow. Your Windows drives are mounted automatically under /mnt, so C: is /mnt/c, and Kirkland notes they’re mounted read and write. His own example was a Visual Studio sample project in his Downloads folder under /mnt/c/Users: he copied and renamed files and did a search and replace with find, xargs and sed from Bash, then let Visual Studio build the result.

The FAQ is careful to say the two sides don’t behave the same. Files under the Linux root are controlled by the subsystem, so they get Linux behavior: case sensitivity, symlinks, chmod and chown, and filenames Windows wouldn’t allow. Files on the mounted Windows drives are controlled by Windows, so they aren’t case sensitive, you can’t create symlinks there, and every file shows full 777 permissions for the user running Bash. You also can’t create a symlink from one filesystem to the other. The Linux side itself lives under your Windows profile in the lxss folder in local app data, which is the folder the FAQ’s uninstall steps remove.

My advice is to decide per project. If you want a Windows editor and Linux tools on the same checkout, keep it under /mnt/c and accept the Windows rules. If a repo depends on symlinks, executable bits or two files whose names differ only by case, the FAQ’s rules say it will behave more like Linux inside the Linux root.

The rough edges they’ve already named

Everyone involved keeps saying beta. Harsh warns that not every Bash script and tool will work and that there will be gaps. The FAQ says some packages use features that aren’t implemented yet, udev for example, which causes errors during apt-get upgrade, and that there are known problems with IPv6 connectivity and with ICMP, which affects networking commands like ping. Kirkland adds that there are still imperfections around ttys and VT100 handling, and that byobu, screen and tmux don’t quite work yet. Turner also flags a known issue that crashes Settings on Windows 10 N editions.

Why shell people should pay attention

The tools named in these posts read like a shell user’s daily kit. Harsh mentions sed, awk, grep and Git. Kirkland lists apt, ssh, rsync, find, xargs, curl, gcc, tar, vim and emacs among the Ubuntu user space you get, and says apt install and upgrade work. The PowerShell team notes that Bash on Windows natively supports the Linux OpenSSH client. The FAQ makes the strongest case for build tooling: plenty of Ruby gems and npm packages have Linux-specific dependencies or assume Linux behavior, which can mean build errors and sometimes runtime errors on Windows.

So my take is to treat it as the glue layer. Pipelines of awk and sed over logs, ssh into your servers, Makefiles and shell scripts that assume GNU tools, and git with the same commands you use everywhere else are a good fit. Anything you need to match production, like a database you depend on or a long-running service, still belongs on real Linux, whether that’s a VM, Azure or Docker, which is where Microsoft points you anyway. And since this is an Insider build, I’d keep it on a machine you can rebuild.

If something breaks, Microsoft set up a GitHub issue tracker, Microsoft/BashOnWindows, for reporting issues, and asks that feature ideas go to its UserVoice forum instead.

The takeaway is simple. This isn’t Linux in a box on your Windows machine. It’s real Ubuntu command line tools running on a new Windows subsystem, aimed squarely at developers, with honest warnings about what doesn’t work yet. If your work lives in Bash, it’s worth a spot on a spare Insider machine now.