Run Bash on Ubuntu on Windows

Since we started planning and building Windows 10, we’ve been talking to a lot of you about what you would like to see in Windows to make it a great place for you to build awesome apps, sites and services for all platforms and all devices.

Many of you told us that working with open-source tools on Windows is often a struggle and that you would like Microsoft to make it easier to use these tools on Windows.

Based off your feedback we’ve done a couple things: First we made investments that improve cmd, PowerShell, and many other command-line tools and developer scenarios. Second we decided to grow our command line family by adding real, native Bash and with it support for Linux command-line tools which run directly on Windows in an environment that behaves like Linux!

To accomplish this, we built new infrastructure within Windows – the Windows Subsystem for Linux (WSL) – upon which we run a genuine Ubuntu user-mode image provided by our great partners over at Canonical, creators of Ubuntu Linux.

In our journey to bring free software to the widest possible audience, this is not a moment we could have predicted. Nevertheless, we are delighted to stand behind Ubuntu for Windows, committed to addressing the needs of Windows developers exploring Linux in this amazing new way, and are excited at the possibilities heralded by this unexpected turn of events.”

— Mark Shuttleworth, founder of Canonical

The result is that you can now run native Bash on Ubuntu on Windows!

You can now run Bash scripts, Linux command-line tools like sed, awk, grep, and you can even try Linux-first tools like Ruby, Git, Python, etc. directly on Windows. You can also access your Windows filesystem from within Bash allowing you to work on the same set of files using your preferred Windows tools or Linux command-line tools:

Caveat Emptor (Buyer Beware!)

While we’re excited for you to try out this new technology, which will first become available in Windows 10 “Insiders” builds after the Build conference, we want to be clear about a few things:

First, this is the first time we’re releasing this technology – it’s marked as beta for a reason: We know that there are some rough edges and that some things will break! Do not expect every Bash script and tool that you run will work perfectly – there will be gaps. But by trying out this feature, you’ll help us figure out what we need to work on in order to greatly improve our reliability, coverage, and reach.

Second, while you’ll be able to run native Bash and many Linux command-line tools on Windows, it’s important to note that this is a developer toolset to help you write and build all your code for all your scenarios and platforms. This is not a server platform upon which you will host websites, run server infrastructure, etc. For running production workloads on Ubuntu, we have some great solutions using Azure, Hyper-V, and Docker, and we have great tooling for developing containerized apps within Windows using Docker Tools for Visual Studio, Visual Studio Code and yo docker.

Third, note that Bash and Linux tools cannot interact with Windows applications and tools, and vice-versa. So you won’t be able to run Notepad from Bash, or run Ruby in Bash from PowerShell.

But wait, there’s more!

Existing command-line tools are now greatly improved thanks to investments made in the Windows Console. We’ve significantly improved rendering performance, added support for more VT-100 sequences, and how it handles complex text layout. We’ve also made some key improvements in how the Console handles High-DPI screens.

These improvements directly benefit cmd prompt, PowerShell, new tools like Bash, the new Windows Docker client, and many other existing Microsoft and 3rd party command-line tools.

Related Build 2016 Content

If you’d like to learn more, you can watch Kevin Gallo’s keynote announcement and demo of running Bash on Ubuntu on Windows at Build 2016.

Join the conversation

“Third, note that Bash and Linux tools cannot interact with Windows applications and tools, and vice-versa.”

I hope that this is a temporary restriction. I’d like to be able to use bash to create scripts to automate tasks for me. In the past using Cygwin, I’ve done similar things, running commands in SQLCMD to make the same updates to several different databases.

Without this ability, then this is just a fun plaything, probably not something I can use to benefit my daily work very often.

You state that you want to invoke Windows tools within your Bash scripts and workflow. What kind of tools, specifically, would you find useful? Could you give us an example workflow that would employ tools on both the Bash and Windows sides?

Not sure if it came across during the keynote, but you can access your Windows filesyste, from within Bash so could use Windows tools and Bash tools to work on the same set of files if you need to.

I am a Java developer, using so far Ubuntu/OS X exclusively for my developing needs. In OS X/Ubuntu I installed JDK of my choice and use it every where. With this “on Ubuntu In Windows”thing do I need to install JDK on both platforms(which is a crazy idea, if that’s the case), same with .Net core and like these there are so many. So without interoperability its just a performance improvement over people already doing this through a VM, including those mounting windows drives inside Linux filesystem. We are all doing this from a long time.
When I saw this news “Bash is coming to Windows” I was ecstatic. I thought the integration is on par with OS X. I wonder how Windows became a POSIX compliant over night.
Hmmm, looks like atleast as of now, this is like a reverse of Wine on Linux. This is not I want. As a developer, I want Windows with Bash power. Just like how Bash is in OS X. Bash must be a first class citizen in Windows eco system, not as a guest who once come in while.

So the core idea here is that we have a seamless environment… I think the default behavior is, since we’re in Windows, we execute Windows apps first and then anything else second. The way we do that is the way it has always been done in Unix / POSIX compliant systems.

The logic here is this (I’m a long time Unix guy, 20 years + 26 using MS as well): treat order of execution like how the PATH is defined in shells with priority based on position in the string (array). So if the user has Windows bin folders first, we execute those; let the user decide and put some sane defaults in place. MAKE IT EASY and simple to get to /Program Files [*]/ (eg, on OS X we can simply do `/Applications/Safari.app/Contents/MacOS/Safari` if we want to launch Safari from the shell and watch the console output for debugging or other purposes!)

You’re going to have a lot of devs and users wanting to edit and launch Minecraft, for example, from the shell.

Frankly, to get a feel for what folks really want to see, go evaluate Babun (Cygwin done right): http://babun.github.io

The only problem with Babun / Cygwin has been that it is not connected with Windows enough. We want to have the full *nix experience with /mnt/, /dev/, /var/log, /usr/local, etc. We want $HOME (~) to be /Users/my_username and not some other location, just like OS X does it.

There is only one Java in Cygwin and I’d expect the same. I’d want to run the “Windows” not “Ubuntu” one.

To be honest I don’t see the benefit of Ubuntu-on-windows thing. It seams to me that I should stick with Cygwin as it is better integrated within Windows for day-to-day dev tasks and vagrant/VM’ed Ubuntu when I need to run a Linux-based server. Could you tell me where I should be using Ubuntu-on-Windows bash over Cygwin?

@Devanand The Bash environment is a high-fidelity Linux-like environment – tools running in Bash don’t even know they’re not running on Linux!

As such, if you want to be able to call Linux java, then you’ll need to install the Java bits into Bash.

If you want a Bash-like command-line, but with access to Windows apps, tools, etc. then Cygwin is a better option since that’s a Win32 ported version of the GNU tools.

HOWEVER, if you want an environment with high-fidelity Linux-like behaviors, then you’ll want Bash on Windows.

Note: Windows and *NIX are fundamentally different in many important ways, both with strengths and weaknesses. As we’ve stated many times now, Bash running on Windows is a developer convenience – it is not a complete platform play.

@Michael: There is only one Java in Cygwin because Cygwin’s tools are simply Win32 ports of GNU tools – they run as Win32 apps because they ARE Win32 PE apps. Therefore, they know about Windows’ environment, processes, filesystem, registry, etc.

Bash, on the other hand is real, genuine Linux Bash. When you run GNU/Linux tools from within Bash, you’re running unmodified Linux ELF binaries atop an API that looks to those binaries as if it is Linux. Therefore, they have no knowledge of Windows, nor of its filesystem, they don’t see the registry, nor other Windows Win32 processes.

We do hear your feedback though and, once we’ve shipped this first version, we’ll start more detailed analysis and discussion about this frequent ask. However, we’re making no commitments at this point that we will/can make what you ask happen.

I personally really like the way I’m seeing this implemented. What I would want from Linux utilities in Windows is exactly what I’m seeing – a subsystem of the Windows kernel that can provide the interface expected by Linux applications.

I wouldn’t want the “java” command in Windows and the “java” command in Linux in Windows to do the same thing – if I use the Linux terminal, I want to run the one that’s compiled for Linux. This is because I now have two options – some programs may provide different features on either OS (unfortunately), so the Linux Subsystem for Windows would be a perfect way to counter this.

What I would like to see perhaps is some extras, like the ability to do a Windows system call from Linux in Windows. I imagine it might be very easy to implement something like that.

Also, what about having a “Program Files (ELF64)” folder, as like a standard way of installing native Linux applications in Windows? Would that be too weird?

What if there was one special linux command similar to windows start.exe, which runs things on windows ?

so…
java [enter]
would run linux’s java
start.exe java [enter]
would run windows’ java.
start.exe somefile.txt [enter]
would open it in windows notepad (or whatever is associated with txt)
start.exe . [enter]
would open the current folder in windows explorer.

as the rest of the world, I am really amazed with “bash on ubuntu on linux”, but had actually solved the problem some years ago:

a) windows is my main OS
b) I have linux running in a minimized vmware windows all the time
c) windows mounts linux via smb
d) I wrote a program called “of” (for both openfile and openfolder) which makes exactly what I suggested above.

the only practical difference is that the machine has a different IP address. the rest is the same.

I just signed up for answering this. What I need is (please, please!):
– Ansible to be able to automate my Windows machine set-up.
– Vagrant to work from this bash shell.

I work a lot with Linux VMs but also write windows software. I do not want to have to change OSs for every customer. One of my customers works on Debian machines, uses Vagrant to launch his VMs. Other customers have Windows hosts. I do not want to have to change OSs.

I came here for this exact same thing: I want the ability to run Ansible, Vagrant, and Docker containers cleanly on Windows via this new toolset. However, this opens a few questions that would need to be answered:

– Will there be a method to keep the Linux subsystem/environment running in the background at all times? Just because I close the terminal doesn’t mean that I want the service to quit. For example, if I were to background an application and close the terminal, I’d expect that it’d still be running in the background.

– Communication between the Linux subsystem and Windows environment, mentioned in an earlier comment by Chris B., highlights an important request/requirement. I REALLY want to use Ansible to control my Windows box using the Linux subsystem, which then can communicate to Windows systems/services on the backend (MSSQL, IIS, etc). This would also be true for monitoring services like Nagios/Icinga, and make deployment of said tool sets very simplistic.

– Assuming cross platform communication DOES work, the ability to query Windows services and/or start/stop/restart services through BASH and/or other shells would be useful. Having to jump between BASH to Windows and vice versa should be trivial, and being able to do everything from the command line would REALLY make life very simple.

– I love the fact that we can install via APT in Ubuntu. I really wish Microsoft would develop a simple repository system similar to Chocolaty for installing applications from the command line. And being able to do so from BASH would be even better.

– Last, being able to make Powershell calls via BASH would greatly improve the integration of automation toolsets like Ansible. Please consider it.

Trust me, we (at Ansible) are watching this very closely, and I’m banging refresh a lot waiting for these bits to hit my fast-ring test box. While we’re making big improvements all the time to managing Windows with a Linux Ansible runner, this could well be the missing link to a supportable Ansible runner on Windows. Ansible on Cygwin is sadly a little too flaky to support (mainly because of our heavy reliance on fork()), though people do make it work.

With the documented restrictions, you wouldn’t be able to do much with a local connection to manage your Windows box directly (since Powershell and other local Windows binaries are inaccessible), but using a winrm-to-localhost connection should work fine (assuming that Ansible works at all, that is).

I’ll be playing around with this as soon as the bits are available- watch for a blog post if I get anywhere useful with it…

Well, as I mentioned, I’ve used SQLCMD. I’ve also used some 3rd party tools, most notably the SQL tools from SQL Accessories. I’ve used XCOPY because the Cygwin cp is far too slow. I’ve used the various Visual Studio command line tools, msbuild, compilers. Finally, I’ve used a couple graphical tools, the one that immediately comes to mind is notepad++.

I am extremely impressed with the concept. These seems similar to CoLinux, which I always thought had great potential. I think you’ll likely have some stumbling blocks along the way. Cygwin constantly has issues bringing in new tools from *nix. They’ve written their own fork(), but it’s very slow. I assume you’ll be able to do better. They also have issues with case-sensitive file names. I am curious as to how you’re handling that. Anyway, I’m sure you can throw more resources at this than are being thrown at Cygwin, so perhaps you can catch up pretty quickly. Good luck, and I can’t wait to see what comes of this.

Thanks Chris. Cygwin is essentially the GNU tools ported to run as Win32 tools. This gives you the ability to use their Bash to directly access Windows command-line tools, apps, etc.

Bash on Ubuntu on Windows, on the other hand, provides an authentic Bash/Linux environment running directly on Windows. Right now, it has no ability to invoke/execute Win32 apps – it’s a relatively pure Linux environment, including enforcing Linux filesystem behaviors when working within the local Linux FS.

But we also mount your C: drive into /mnt/c/ and maintain NTFS’ case-agnostic behaviors.

Personally, I think that is a great approach. Cygwin I always found problematic as you get the confusing mix between the two, In particular things like did you pick up the windows binary instead of the cywin one. This gets tricky in someone else build scripts and tools, especially if they are existing cross platform handling.

I’d suggest that launching processes between the environments with a explicit launcher binaries would work fine. Those who want to run windows processes can use all the power of bash aliases and scripts to launch exactly what they want when they need it, without getting into potential confusing mess.

so, I don’t particularly enjoy editing files in the terminal. I’d far rather edit them in a GUI-based editor (Sublime, Atom, etc.). From what you’re saying, if I were in bash, and I needed to edit a file in a directory i’m currently in, I’d have to find out where it is, translate that into a ‘windows directory address’, and go into explorer/powershell, find the file then open it? That seems a bit over the top.

It says, when I try to run `open`, that there is no valid file descriptor available to the terminal. I’m not sure exactly how this is being implemented on the backend, but surely if you’re able to mount the filesystem, and pass through the internet connection, etc, there’d be a hook in there to allow files to be opened in linux from ubuntu.

Rich, this is excelent news but i have to agree that we need to be able to interact.
I currently work in automation and this would be a tremendous limitation, i currently use msys2 as my base for ruby/python/bash scripts.
As well as for compiling other native tools, i love the current interaction i have as i can call Eg: Get-ChildItem | grep thething.
Or do all my work from powershell and then run make over a Makefile on an existing build project in golang/ruby/etc.

Otherwise i would have to keep using MSYS2 or something as switching consoles is not really that efficient.

I have this problem with the Evince EPS viewer. There is a Windows binary which uses the windows display manager and the “gnome binary compiled for cygwin”. I specify which I want to open using an alias in my .bash_rc file and/or symbolic links to /usr/local.

This scenario happens a lot. I think the best way to interact with Windows programs is to use the equivalent of cygstart which would open a file using what ever Windows defaults to for that file type.

Rich – with all due respect, anyone who’s been developing on the Microsoft platform for years has seen this before. Instead of improving the tool you have (PowerShell) you’ve gone and built a whole separate stack. Now we’re going to have to switch back and forth, applications are going to have to support both (or neglect one), and you folks will be asking us about “scenarios” while you’re running around like one-handed wallpaper hangers.

Here’s a scenario:

I have a huge pile of text files in a directory structure. I want to grep the files, then pipe the result to, say, R, which will pull some information from SharePoint and SQL Server Analysis Services, then take the results and generate a page in Ruby and post it to IIS with PowerShell.

How many times am I going to have to copy files back and forth between shells?

Why didn’t you just enable the BASH behaviors and tools inside PowerShell where they could interact transparently from a single script? Then everyone at Microsoft could focus their energy on PowerShell instead of wondering which direction DevDiv is drifting during this product cycle.

Personally, I take this as a sign to immediately STOP recommending **any** scripting on the Microsoft platform and shifting all scripting work to something else. Because based on a very long history of being burned by dropped platforms (smart tags, information bridge framework, infopath, SSRS extensions…) the writing is on the wall for either PowerShell or this BASH integration.

I am curious to why you need to copy the files between the shells since the underlying filesystem is available to both shells at the same time. You might need to save the piped output to a temp file if you want to make a long pipeline that should cross the boundaries, but I see that as a minor convenience.

Hi Rich,
I have long used Cygwin to be able to run the standard bash tools on Windows, as well as ssh’ing back to a “real” Linux box. I think it will be great to be able to run Linux commands natively with a compatibility later, and look forward to see how this works in practice and how MS continues to advance this capability to do things like running Docker directly instead of having an extra VM on the host.

In regards to running Windows programs from bash scripts, I can give you an example. I have many bash scripts that use awk, grep, etc. to manipulate the output of other bash scripts, and that also make calls to Windows programs to do part of the work. For example, running Unix “make”, to generate binaries, then running “jlink” to load the binaries onto an embedded processor (in this case cross compiling).

Further to this hybrid model would be having various internal tools created in everything from .NET to Win32 tools, and being able to mix/match them with the better stream manipulation and scripting from Bash. For many setups, this would eliminate the need to have Cygwin installed, and keeping it up to date.

This is certainly a step in the right direction, but the inability to launch Windows binaries from within a WSL environment is disappointing and constraining.

On our end, it would be nice, for example, to use the same build system that we use for Linux, MacOS X, Android, etc. and be able to use MSVC as the compiler. Right now we either have to build using something like MSYS/cygwin (what we do), or create an entirely separate build system just for Windows.

Likewise, administrators could write unified bash scripts that perform admin tasks — on windows, these would use reg.exe, net.exe, etc.

Hi mate, I’m in the same boat, I’d like to offer my feedback.
I have Sublime Text 3 installed. Under a unix environment, I can make a symbolic link in /usr/local/bin (or another path variable) called sublime, then in bash run “sublime filename.txt” and it will open the text editor to the specified file. Will this be possible under this bash?

The problem is with multi-platform targetting using POSIX/Linux tool chains.
The example that gets me is the testing and building of Apache OpenOffice. It targets *nix, OS X, Solaris, OS/2 (yes), and Windows. To use the same generic processes and a bunch of custom build stuff, doing builds on Windows for Windows now requires Cygwin and the Windows SDK and Visual Studio VC++ compiler, along with all the GNU/Linux-isms. Hey, the target is Windows and the compiler is admired for this. Even if there was some effort to switch to CLang, it might well be the Visual Studio front-end.

If we had “start” built into the bash shell, that might be good enough [;<).

It's true that one has to avoid path rewriting or passing in "/" path separators, but that can be handled inside batch files, which do run under CygWin, MSys, etc., and there is always the crafty use of @-includes on utility command lines, such as for CL :). I can't go back to the POSIX Subsystem on Windows, but I recall that one could cross environments in a similar manner.

One example is that it’d be nice if Visual Studio Code could “see” the Git installation on WSL, so we could get rid of Git for Windows. As it is, we’re going to end up having to install and maintain lots of the same stuff twice.

1) Provide enough compatibility that I can install and run virtualbox, vagrant, and other popular tools via apt-get in Ubuntu-on-Windows.
2) Provide the ability to specify specific commands that should pass-through to windows commands. For instance: I could set up an pass-through/alias so when I type a “vagrant up” in Bash, it actually executes vagrant on windows and the interaction is displayed as if it’s in Bash.

To add on to what Rich said, bi-directional interop with Windows & Linux processes is something we are very interested in enabling. However, we want to know the specific scenarios you have in mind so we make sure to design the feature appropriately.

All of my software products Heimdal, OpenAFS, AuriStor File System, etc. are complex cross-platform products that share the majority of its source code with the builds for Linux, OSX, Solaris, AIX, etc. Our build processes make use of Git, Gerrit for code review, Buildbot for continuous integration builds, C-Tap and Docker for automated testing, Coverity scans, etc. All of the builds rely on command line tooling. For Windows builds a combination of nmake and msbuild as well as many Unix tools. A partial list includes:

Today we use Cygwin or msysGit tools to provide the required functionality. As opposed to working with Canonical to bring yet another bash shell to Windows, what I would prefer to see is Microsoft work with Red Hat and the Cygwin community to better integrate Cygwin with Windows.

To be clear, the functionality that I require is to have the same suite of command line development tools on Windows for building Windows applications that are used on the *nix platforms for building native binaries on those platforms.

Some features that I think would make this useful compared to VMs or the new Docker for Windows:
– Being able to launch linux processes from Windows (I guess it’s already possible with a bash command_name, under cmd?)
– Similarly being able to launch Windows executables from within bash. Having to leave bash, retrieve the file in the right folder to edit it with VS Code was a bit pathetic unfortunately. We should be able to do something like: vscode file_name, under bash, or at least have a “win” command that can be used to launch windows processes with something like: win vscode file_name.
– Some kind of basic inter-process communication protocol between windows and linux processes (piping, shared memory, or even a simple/hacky file system based approach since Bash already has access to the Windows file system).
– Full integration with Visual Studio 2015. Being able to build ELF binaries with GCC and debug them natively inside Windows (without using the remote debugging feature).
– Offer the open source community clear best practice Guidelines on how to integrate Windows and Linux dev workflows with bash scripts (How to handle long folder paths, ssh scripts involving folder names with spaces, etc…).
– As a Scala developer for instance, I’d prefer to use bash scripts to build complex Scala projects in the Ubuntu environment while using the Windows installed JVM for testing etc. This sort of thing is already possible and is part of the Scala distribution, which uses Git’s MSYS bash. Doing it with the new Bash for Windows needs to be even easier.
AFAIK Most hipster devs are using overpriced Macbook Airs because of the fully integrated Unix environment it offers. Bash on Windows is a great step to win them over, but better integration with existing Windows infrastructure is crucial.

My #1 wish list item in terms of Windows integration is the the is 2nd bullet Omar Reddam mentions above:
– Similarly being able to launch Windows executables from within bash. Having to leave bash, retrieve the file in the right folder to edit it with VS Code was a bit pathetic unfortunately. We should be able to do something like: vscode file_name, under bash, or at least have a “win” command that can be used to launch windows processes with something like: win vscode file_name.

I see my myself using bash/ubuntu commands for all the CLI stuff (as that’s how I use cygwin today) and Windows apps for all the GUI stuff, but the former needs to able to launch the latter, from the command line. That includes the need for path translation.

Somewhat related, I’d love to eventually see Microsoft add conventions so Windows GUI apps (primarily programmer focused utilities) can say they support forward slash delimited paths & users (developer types) can set a Windows preference setting to use those by default with apps that support them. That can (eventually) make / vs \ path annoyances a thing of the past for Windows devs. But for now / to \ path translation is needed when bash launches Windows programs and passes path arguments as command line args.

The request for interop between Windows and Bash/Linux is something we hear loud and clear. If and how that is manifested, however is a complex problem with interesting repercussions that we need to very carefully analyze and discuss.

We hear you. We get it. We’ll be looking into this. No promises at this time 🙂

Rich,
I’ll give a developer focused example of a reason that interop is necessary. Javascript Unit Testing using a test runner such as Karma generally need to be able to launch an instance of a web browser and communicate with it.

Being able to launch VSCode or something else is obviously nice to have, but it probably isn’t as showstopping as being unable to launch a browser for running unit tests.

You may wish to look into emulating the behaviour of the Linux binfmt_misc handling – using a compatibility shim executable and treating PE as a hardcoded case. If properly implemented then the guest GNU environment could use the same infrastructure as per native Linux to execute other code too (Java, 16-bit DOS) or even to try to supplant the native shim with say a WINE build in the guest environment.

Here is a scenario that I am currently using, and I currently need Cygwin for it to work:

I am developing embedded applications for ARM Cortex microcontrollers, I am using Eclipse as an IDE and the build process is controlled by a Makefile.

* Eclipse (for windows) prepends the cygwin-Path, then calls make (from cygwin)
* the makefile is using cygwin bash as its shell and using various GNU tools, especially stuff like mkdir and rm which are incompatible with their windows counterparts,
* the makefile needs to execute a bunch of Python scripts that generate c code for some lookup tables
* the makefile is also calling arm-none-eabi-gcc (and some other tools) from the native windows port of arm-none-eabi-gcc (Eclipse also wants to use the gcc binary to be able to configure all its code intelligence)
* the makefile will also call the proprietary J-Link-commander tool (jlink.exe, native windows) to access the J-Link programmer device to flash the image to the connected hardware (proprietary tool, proprietary windows USB drivers)

The same Makefile would run natively on my Linux Box (with the Linux version of J-Link and the Linux drivers from Segger), indeed I have carefully designed all aspects of the build process so that it could run on all platforms that have the GNU tools in the PATH.

But If the make and bash on Windows would not be able to call the Windows version of the segger J-Link tool or if the Windows Version of Eclipse would not even be able to start the linux make in the first place then everything would be of absolutely no use for me. I would still be stuck with Cygwin.

It is of essential importance to be able to seamlessly call tools across the windows/linux boundary to get real work done with real tools or otherwise it would just be some funny sandbox of very limited practical use.

I have this exact scenario at work as well. This is the scenario Marvell uses for its IoT platform. I know Azure has worked with Marvell chipsets for their IoT platform, so I was hoping that Microsoft would’ve made it possible to call make from Eclipse with this inclusion of the Linux subsystem. However, it seems that this is not the case. I was excited for this feature so that I could finally drop Cygwin and use a more “native” approach. However, it appears that I have been let down by this Windows “feature”.

One example is that it’d be nice if Visual Studio Code could “see” the Git installation on WSL, so we could get rid of Git for Windows. As it is, we’re going to end up having to install and maintain lots of the same stuff twice.

I would agree with you Chris, If it becomes a sort of sandboxed vm within windows than my response would be thanks but no thanks, if i happen to be on windows and i need to ssh with my credentials or something, then i would not have to configure putty but that’s the only thing i can think of that i would do different.
I am certainly not going to change my workflow for that.
but for sysadmin stuff or development without a “real” marriage between the systems this is nothing more then a gimmick. I hope you do find a way to make this happen because i see this as an interesting development that puts some heat on canonical as well as benefiting quite a few users.

Simply put, this isn’t going to be possible because we’re talking about user mode isolation, similar to how Docker containers actually work. Kudoz to Microsoft for not taking the simple way out here. Multiple user modes is the equivalent of having parallel worlds. They don’t know about each other.

On that note, you can still open sockets on localhost and communicate between programs this way.

Great information given by Chris Breisch. But if you just want to practice the linux command in windows you can use a tool.
Lots of people are just want linux for practice the linux command. And they cannot learn because windows have not terminal.
I am one of them so here is a best suggestion: http://www.trickstable.com/?p=1130

This was helpful in an effort to use bash git-ftp to update my (cheap, shared) server from git repository. Everything installed and and the run kicked off when I got to my repository directory using /mnt/…
However, git-ftp on WSL Ubuntu always believes that we have a dirty repository, with uncommitted changes. When I finally figured out that using the git shell (GitHub), everything works correctly, I confirmed that there is a bug to be addressed in Windows Subsystem Ubuntu implementation.

Hey Suman.
Note that you can access your local machine’s drives from within Linux – they’re mounted under /mnt. For example, your C: drive will be under /mnt/c/.

This means that you could use VSCode to edit your Ruby source code sitting on your Windows PC and then switch to Bash to build and run using Rake/Ruby. This is particularly useful if any of your Ruby Gems contain Linux dependencies; they should run within the Bash environment, whereas they’d fail when run in Windows.

As I mention above to Chris, we’re interested in what kind of process interop you’d like to see in the future. What Windows apps would you like to call from Linux, and vice versa?

Hey there Rich, great work!
Continuing on this topic about interop, one thing that comes to mind is integrating git in some tools (like VS Code running on windows). If we don’t have that interop, we’d have to install both git from apt and git-scm.com in order to be able to use it from bash and from VS Code – if that’s the case, then it’s better to use MSYS2 or Cygwin, as those work from the terminal and from windows itself.
Also, if that interop was working, I would be able to use bash vim to work on my win32 projects, by running cl from vim and compiling from there. Without that, again, I’d have to install both ubuntu’s vim and a win32 compiled vim in order to work on win32 projects.

Nevertheless, I think this is a big step in a great direction, looking forward to testing this. Do you know more or less when this feature will be available to Windows Insiders?

Will bash ne compatible with lumia 950 XL with a display dock connected si I can clone git repo and édit locally with emacs/vim? Lumia 950 XL with display dock lack Visual Studio Code compatible and this would ve a good alternative 🙂

Pretty exciting stuff. Continuing on the point about interop, it would be nice if Windows GUI applications are able to run Linux command line tools with arguments determined at runtime and then capture the resultant output. The use case that I would like to see supported is the ide-haskell plugin for the Atom editor being able to run ghc-mod (a linux command line tool) with a path to a file as an argument (this is a temporary file generated by the plugin from the current state of the editor, the source code file, cursor location for type inference & etc.) and then read the output. In this use case I think being able to read the buffered output on the termination of the process is adequate (instead of having access to the output as a stream) as the process is short-lived.

WSL is different: It’s largely the implementation of the Linux syscall API’s + supporting infrastructure. It’s been designed to be largely userland agnostic: For this first version, we’re focusing on building a great Ubuntu experience, but we’re interested in exploring other distro’s too in the future.

Yay! Alpine would be a great choice for your next distro. Why? Besides its small size, it has been chosen as the next docker base system, meaning you can ensure that your working environment matches as closely to your release environment as possible.

Are mechanisms of calling POSIX functions going to be exposed to userspace developers? It’s interesting if other Windows developers can also come with other implementations of this kind of shell, scripting system. Or is it just “closed API”, hands off, don’t touch?

This is very exciting news. Now I can play games and have a proper command line without rebooting. 😀
One question, What is the possibility of running a GUI application from the unix shell? For example, I would like to run an instance of eclipse pydev which uses the unix libraries. In other words, I want an IDE to use the unix toolchains, and do normal debugging work on it. Would it be a possibility in the near future?

What about game developers that are trying to cross compile? Like me for instance. For me to test my code on linux to see if its working well, I would have to boot up a separate machine (not a vm, since you need full GPU support and power) and test the code. It would be a “game” changer for this functionality. This is a good step forward however! I do love the direction you guys are going! Keep it up <3

I was thinking the same thing, but it became clearer that Windows is now capable of running the actual binaries from Ubuntu. This means you won’t have to recompile from source code, or reply on a separate user supported repository.

Imagine you’re a Ruby developer on a Windows PC. You incorporate several Gems into your project. Your project no longer builds or runs because some of those Gems are either wrappers around Linux binaries (libs etc.) or depend on a particular Linux behavior, filesystem layout, etc.

So what do you do? Fire up a VM and try to push your code over into the VM and build and run it there. Every time you change the code?

Alternatively, with Bash on Ubuntu on Windows, you’ll be able to cd to the source code, run rake to make your project and run it because the Ruby tools and your code are running in what they think is Linux, and because we are able to run Linux binaries without modification, on Windows.

This is a VERY common experience for many Linux, Java and other developers working on platforms with considerable dependencies on Linux.

> This is a VERY common experience for many Linux, Java and other developers working on platforms with considerable dependencies on Linux.

I agree completely, which is why I tried to install JDK. However, both the OpenJDK 8 and Oracle JDK failed to install via apt-get. Hopefully the next patch sets up the environment so this kind of task “just works” as I would honestly expect.

“Third, note that Bash and Linux tools cannot interact with Windows applications and tools, and vice-versa. So you won’t be able to run Notepad from Bash, or run Ruby in Bash from PowerShell.”

this is rather disappointing.
im not sure of the point of having a bash prompt that cant interact with native windows command line apps, cygwins been doing it for years. and if you load enough 3rd party software ( mostly from sourceforge) you can get a pretty close approximation of a linux command line.

all of the “server workloads” (git/ruby/perl/apache/mysql….) that this is not for running with already have good windows ports. or if im testing/developing for a system that will be required to run on a azure/hyper-v ubuntu box why wouldnt i develop in the same environment not some quazi functional emulation. that way im testing permissions, SELinux and iptables rules and actually developing in an environment that will properly simulate production.

heck i cant even pipe grep/sed/awk output into osql with this.

rather how about just spending a weekend and knocking out a native ssh/scp/sftp commands/powershell modules and add some of the more common commands natively such as less, sed, awk, tar, wget, vi…

Exactly, without interoperation of win and linux shell it’s not really much better than having virtual machine installed / in VM it’s also simple to share folders to win.

I would like to write bash (.sh) scripts for improving workspace. Eg. do something in bash and then open win application like IDE, notepad++, or other. Also still there will be need to install and configure GIT in windows and also in linux to be able to use it in both platforms.

I’d also like to voice my support for the request to be able to run native Windows applications from bash. I work at Mozilla and support our build system, which currently requires an msys install along with a number of other tools. We were quite excited to hear about this work because we’d love to have a well-supported POSIX shell environment to use for building Firefox, but we need to (at the very least) be able to invoke Visual C++ from our build scripts.

This looks great, though! One of the biggest complaints from myself and other developers has historically been the lack of a standard POSIX shell on Windows, and this looks better than I could have imagined!

Can you add the option to open the bash in the extended right click menu below the option
“Open command window here”
?
I’d like to use it to quickly open a bash command when I’m on a directory and I want to execute a linux command line command or just open an UIless linux application.

Me too fails to identify the functional benefit here:
There is nothing new with “Applications running on one operating system instance accessing file systems available to multiple different operating system instances”.

The key feature missing here is:
“Run a Windows application from within a Linux application, with synchronized access to the same file system(s) and with stdio redirected”, as it is possible with SfU/SUA and Cygwin, as well as with Wine inside Linux – even if each solution does have its own limitations:
SfU/SUA: end of live (we do use it for production!)
Wine inside Linux: does not support Visual Studio (and others)
Cygwin: fork() breaks when updating running Cygwin binaries (brand new patch available)

We do have a *nix-based build- and packaging-system (bash, GNU make, autotools, libtool, …) running on many *nix as well as SUA, which knows how to execute the native Windows toolchain (cl.exe, link.exe, lib.exe, …) as well.

While the application source code (C/C++) itself is ported to the native Windows compiler (minor difference, it is C/C++ after all), the build system is not (major difference, and we don’t want to maintain two distinct build- and packaging-systems).

We have tried some kind of “Remote EXecution” already (https://github.com/haubi/rex), which we got to work for demo mode, but (let alone performance) failed for production use due to filesystem synchronization issues.

The idea is:
Within Linux, register a binfmt_misc handler for Windows executables, and when some Linux application (gmake, bash) is about to execute a Windows application (cl.exe, link.exe, cmd.exe, …), the binfmt handler does (remotely) execute the Windows binary, and redirect stdin/stdout/stderr (at least) in both directions – much like Wine already does.

The key issue here is with file system synchronisation:
Any file system content written by Windows applications has to be visible to Linux applications as soon as it would be visible to other Windows applications – and vice versa of course.

Example:
When (the Linux application) gmake does (run some code to) create the source.c file, and executes (the Windows Application) cl.exe to create source.obj, then source.c needs to be available to cl.exe as soon as it would be available to (the Linux application) gcc.
Consequently, when cl.exe successfully returns, source.obj needs to be available to gmake as soon as it would be available to (the Windows application) nmake.exe.

Looking forward to see remote-compiling (to some degree like cross-compiling),
/haubi/

Will the Linux ABI be ported to x86 (i.e. 32-bit Windows 10)? I have a 7″ tablet with 32-bit Windows 10. Otherwise I will have to use Cygwin there and Ubuntu on Windows in my 64-bit laptop. Right now I’m using Cygwin in Windows 10, but would like to switch to Ubuntu for Windows since it has more packages, and I’m also using Raspberry Pi:s with Raspbian and Ubuntu MATE which are more like Ubuntu than Cygwin.

I think it is great this initiative is coming from Microsoft themselves, but because it is, it is somehow disappointing in my opinion.
First off, this kind of applications already exist, its not really integrated but something ran inside the classic windows command line. More interesting would be it being an alternative for the classic command line and not a kind of virtual environment inside of it. Take an example of bash, z shell, … all “living side by side”. I know this is a much bigger afford to get the wanted result but it is the only way to make windows attractive for developers and users that abandoned ship for Linux. Because that way there would be an possibility to get the flexibility between command line and windows applications that already exists in (lin/u)nix environments.
Second, but somewhat unrelated I think, it would be great if Microsoft gave the possibility to chose what window manager to use, and not with slow 3th party software that already exist. It would be really nice to have awesome wm, gnome, … or windows 2000 style (including start menu) working natively on windows 10.

Glad to see NT’s subsystem support has made such a prominent comeback! Always felt it was an awesome but sorely underused piece of engineering since the days of OS/2.

Not sure if this can be covered in just one reply but I’m really curious as to how exactly can you access processes running on the Linux subsystem from within the win32 subsystem.
You’ve stated that, say, calling explorer from bash is impossible, so, I presume this means that there is no communications layer between subsystems yet somehow you have to display bash within a win32 window and route all the relevant user / system events from the current win32 session to that bash process running on the linux subsystem.

How is this done? Is data being routed through SMSS (which might explain, I suppose, why you can’t just call explorer.exe from bash for instance)? Also, (this is more of an idea for a “why the hell not?” project than anything practical in particular) would it be possible to change the default subsystem being loaded at startup or are there too many hardcoded win32 dependencies to make that possible?

“Why the hell not” encouraged me to create a hack to at least allow the pseudo execution of .exe from bash. Don’t know if it is still relevant to you but if it is: https://github.com/JakeSchieber/bashex

This is a really interesting development. If the workflow on Windows to work with open-source projects is as easy as it is on Linux, I’ll definitely give it a try. I’ll be trying to run Apache ZooKeeper and Kafka on my Windows PC, rather than in a Linux VM, just as a local test environment while I write my code. Eventually, it will be deployed on to real Linux but, for my dev environment, I’d really like to use Visual Studio for editing and bash to build and execute.

Will bash scripts executable (by double click) in Windows Explorer? And can you drop files on the script and have the file names passed as arguments (like batch files)? It would be extremely useful to have hashbang support in Windows. Then a person could write scripts in an language they are comfortable. https://en.wikipedia.org/wiki/Shebang_(Unix)

It seems that a major goal of this project is to make certain Windows remains a viable development platform without forcing Microsoft to dedicate developers to port every new project to Windows (like they have with redis, node, and many others). That’s fantastic. This benefits everyone. But I really think you should focus attention on supporting interaction between the Windows utilities and the Linux ones.

Compared to running Linux in a VM, this solution certainly make networking and access files between environment much easier. But the user still has to worry about two separate environments with their own PATH and their own installations of git, awk, du, python, java, etc. And there’s a downside. VMs can more accurately mirror the production environment and can be easily backed up, cloned, or sent to another developer.

Please don’t stop short of making the environment developer truly need to be productive. Many developers and admins currently use GNU tools to fill in the gaps of the Windows utilities and PowerShell. This wont help them. Think of amount of effort developers put into automating repetitive tasks, but the best environment for a productive developer.

I think, from my understanding, the name “Windows Subsystem for Linux” makes sense, because that part of the kernel will be providing the interface provided by the Linux kernel to run Linux applications.

However, as for the rest of it, yeah… technically none of this software is Linux, with the debatable exception of Git, as it was developed to develop the Linux kernel.

Well… They definitely stated that they have made a *Linux* compatibility, not just POSIX compatibility. They are not running Linux kernel, but they are simulating it! It means they support Linux ABI, not just API. Programs that run on Linux don’t have to be recompiled.

I am ***BAFFLED*** that nobody commenting here does see this is just coLinux reimplemented by Microsoft and Canonical.
I only wonder why did they reinvent the wheel instead of patching coLinux to work on 64-bit and improve it’s installer.

They are not porting a Kernel or something, they redirect syscalls to win api, nothing else, this is not “linux” is GNU with GNU Tools and some open source software, not even a single thing from Canonical. There is no Canonical software there, just open source created before that crappy company existed.

The most interesting Linux-like environments around today to me are the LX-branded zones of Solaris/Illumos and Freebsd’s Linux emulation. I was really expecting something that could eventually compete with LX zones and that incorporates some analagous more robust system call translation layer.

For day-to-day developer productivity I usually prefer building my tools on Cygwin even when native Windows ports are available. Cygwin is generally very usable and integrates well with my workflow. Performance is adequate for most purposes and even complex graphical programs function better than I ever anticipate.

It would be useful to have an alternative to the “visual studio developer prompt”. The huge chain of batch scripts that set up the necessary environment for msbuild is absolutely horrible and I couldn’t port it to another language by myself. I’d like to be able to bootstrap arbitrary processes such as a cygwin terminal emulator or maybe something running under this new environment but that seems to be nontrivial.

If someone knows when will it come live to non-Insiders, an approximate date, it would be nice. But I think it will need to be first tested by Insiders for a few months, in order to get details about usage, problems/error reports, fix it, re-test, etc. then, it will be released to non-Insiders.

After reading all previous comments, it seems that:
1. Windows should do away with cmd and ps, and make bash its command line tool that can also support linux filesystem and executable.
2. Or better still, Windows should do away with NT kernel and put Resurrected Microsoft Xenix ( or Microsoft Phoenix ) at kernel and put MSWindows above it in place of XWindows.

Considering the second part: this way of thinking implies ignorance. The one who thinks this way does not realize the fact that NT kernel is so much superior to every POSIX kernel, just because of all the new abstraction model it has. POSIX abstracts to files. NT abstracts to objects. And that, my friend, is a big deal.

This is an awesome start down the right road for increasing developer velocity on Windows. I’ve always found when working in an organisation with mixed infrastructure has forced a decision of whether to use Windows and get nice easy domain/permission integration or Linux and get nicer development.
In an effort to have my cake and eat it too I’ve been trying to run bash in Windows for the last few years and the best solution I’ve found so far is to use ConsoleZ as a terminal emulator and bash inside Msys2, which mimics a bash environment in win32 (and runs a translation engine to translate Unix paths to Windows paths when calling commands, so it’s possible to run win32 apps). This solution has been essentially good enough for a while now, although it has a few annoying limitations (specifically that there are limited packages available, as they need to be manually converted from Unix packages, and that the translation engine often gets things wrong). I’m hoping having a native solution built into Windows with official support will make this experience even better.

Having used an environment like this for a while I’ve found the following things to be useful:
– Having a shared home between bash and Windows, rather than making a totally new /home/$USER in the context of bash (so all those useful settings files can be used in both, such as ~/.aws, ~/.vim ~/.chef and so on)
– The ability to run win32 applications from within bash*

And the following to be difficult:
– Symlinks. Neither Cygwin nor Msys actually use Windows’ native symlinking ability when calling ln (Cygwin mocks it using pointer files and Msys just does a copy instead). Having ln -s actually create a true windows symlink in the filesystem would be excellent.
– Permissions/chmod/mounting: I noticed in the demo that /mnt/c was mounted as 0777, so it seems like it’s just a normal ntfs mount from within Linux. In that situation normally chmod won’t work as the permissions are set at mount time and can’t be changed. This is a difficult issue to deal with and can actually break some things (for example Ansible will complain if a file is marked as executable when it shouldn’t be and fail, so if you can’t chmod then you’re stuck). This might be a matter of Microsoft producing an official and better featured mount driver for Linux which allows those sorts of operations and handles them within NTFS.

All this being said a lot of the reason I use bash in Windows is because I want a more powerful and usable terminal, not specifically bash, so I think the work being done to improve the Windows terminal is just as important.

* Due to the way that bash is going to be implemented natively I doubt this will work and in many ways having a true Linux environment is better as there less likelihood to get random, hard to diagnose compilation failures when using something like Msys2. That being said it’s nice to install something like the Chefdk or Docker Toolbox and have it available both within bash and Windows immediately so long as the binary is in your path. Realistically this is probably something that you might not need to tackle and that software vendors might start to address in the future (e.g. when you install Docker Toolbox on Windows 10, it installs both the apt package and the Windows binary) but I think it’s worth coming up with a standard or at least opening a dialogue on how this should be tackled in future.

Bold step forward to make windows command line more powerful. Glad to hear this and excited. I always wished Windows had native ssh client to connect to Linux system. This is not in the list of programs mentioned in the post, if it’s not already part of the programs supported, I hope it would be considered for future inclusion. A Terminal with tabs and a ssh utility is all I miss on my Windows. Hope it would be a reality soon! Btw, I author this blog http://www.windows-commandline.com

Do you think this will change the way Docker runs on Windows? The new Docker for Windows is a giant improvement over Docker-Machine, but the DOCKER_HOST still runs in a separate Linux VM. With Ubuntu integrated natively into Windows, will we be able to install and run Docker directly?

No – Bash on Ubuntu on Windows is simply a local development tool. It is not built for running complex setups, nor is it well suited for production server workloads. That’s where Docker, Hyper-V, Azure, etc. shine.

this app sounds great. very few people (as opposed to how many I expected) are talking about this as it is. it’s linuxe. i really hope it will be opensource. i’ve seen the devs. hardworking people, that did an amazing thing that should be advertised as such. it’s an ELFemulator. it’s brilliant.

my only concern is that i don’t want to run a canonical flavor linux and i really hope they wont force me.

open up m$ 🙂 now in my 4th decade of living, i really really love this project of yours.

Thanks guys for this, I am extremely excited about this technology and can’t wait to try it out.
For those that are disappointed in some of the limitations like not being able to run Windows commands from within Bash, I want to share an insight that I have had: at Build, it was mentioned that the Linux subsystem runs in kernel mode as part of the system. If Microsoft’s intent was only to provide user land tool compatibility, it would have made far more sense from a reliability standpoint to implement the syscall translation layer as a user mode driver or application. Instead, to me it seems they are taking care of some “low-hanging fruit” while leaving open the possibility of Linux becoming a far more important part of the system, like the BSD subsystem is to Mac OS’s Mach-based kernel.
Obviously tighter integration between Linux apps and Win32/.NET/UWP apps will require much more work, not just on the Windows side but probably also within the open source software intended to be run. This move, while bringing some much needed albeit limited functionality to Windows, may also help convince various open source groups that Microsoft is serious about open source and open to working with them to enable some of the more interesting usage scenarios.
That’s just my $.02 and why I am extremely excited about this move.

This is seriously, actually awesome. While I wholeheartedly agree with the necessity of more interoperability between WSL and Windows applications, I caution against achieving that in a way that compromises any of the features already developed, because the ability to natively run ELF binaries is unimaginably powerful, and just really cool.

This is a bold step, but bold is not enough. Guys did great job of figuring out the trend and making a feature. But the next step is to go from feature to systems approach.

Instead of building a bicycle, we all now need to think what should the OS of the future be like. Do we want this hack in our systems? Or do we want a definite solution that can extend to our desire? I’ll vote for the second one.

I think the concept is meant to be separated into several aspects: one is running ELF files on NT, another is having POSIX syscalls, and third is… well, just having Bash on Windows. And not just Bash: Csh, Zsh, there are plenty of shells out there in UNIX world.

But the point is in understanding the problem and making an adequate approach.

So from what I understand, Ubuntu will be integrated into Windows but will remain distinctly separate? Meaning tools and apps installed using Ubuntu’s aptitude package manager will be runnable only within bash and bash will not be able to run windows applications?

Does this mean I will have two completely different working environments?

I just wish Microsoft had some focus on adding support for displaying Xorg apps in Windows. This would make the entire thing perfect. There are some Linux based graphical apps that I have worked with in the past that simply do not run on Windows but are useful but it appears Microsoft isn’t interested in making this happen, only focusing on command line? I don’t care if the apps look cosmetically pleasing…

One of the limitations I just ran into and hope will be supported in the future is accessing connected USB devices from bash. For example, if I connect my Android device, I would like to be able to use adb and fastboot from the platform tools in order to interact with those devices. When I installed fastboot and adb using apt-get in the bash shell, neither are able to see my connected Android device. Any plans to allow this type of interaction?

I’m in the same boat. Installing the tools was dead-easy: `sudo apt-get install android-tools-adb`, but they’re useless because ADB can’t see the devices. When I try to run `sudo lsusb`, I get “unable to initialize libusb: -99”.

Seemed like an obvious enough issue; install libusb so I then did `sudo apt-get install libusb-1.0-0-dev` and tried `sudo lsusb` again, but no change.

ADB works fine in CMD or PowerShell so I know the device is seen by Windows just fine. What’s missing here?

I very much appreciate the idea here, but my first though was how great it would be to build/run ffmpeg this way instead of having to cross-compile for Windows elsewhere, but I expect I’ll have similar issues with opencl and decklink support (PCIe device access). If I’m right, this might be a great build environment, but to what end? “It’s not a server environment” so building server tools for this platform is pretty pointless and if we can’t access hardware, there’s just not much actual use for this. It needs a more complete implementation and once it does, I’ll be in heaven; having all the power of Windows and Linux at the same time.

Although the idea sounds great, the statement that “Bash and Linux tools cannot interact with Windows applications and tools” seems quite general.

Is it/Will it be possible to combine use of the Linux tools with the VS2015 Tools Command Prompt?

For example, many C/C++ projects I work with require to run Linux tools as part of build steps (run from MSBuild pre-/post-build events, .BAT scripts, etc.). Currently, those tools are provided by GnuWin32.
For example:
1) build.bat runs sed to process some text files, then runs MSBuild.exe or CL.exe, etc.
2) msbuild.exe my.proj runs a task which calls sed

Would it be possible to replace GnuWin32 with the WSL for such use cases?

I guess, it would not, but I’d like to hear confirmation, if possible.

Hey Mateusz. Not at this time. There is currently no interop between Bash on Windows and the rest of Windows. Our goal for this first version is to create an authentic Linux-like environment so that you can work on open-source projects that depend on Linux binaries/features/behaviors.

We hear your ask and understand your request though and will examine the interop story for future releases.

I have looked forward to this since announced…however it doesn’t seem to work. Installed the 14316 release and enabled developer mode, enabled Linux in programs and features, opened a command prompt and typed bash…

It downloaded from the windows store…and then promptly gave an 0x80070057.

I haven’t even been able to create symlinks on the Linux FS. I went through and create a new user, including all the trappings, and then tried to install, setup or use node.js. I tried 3 different methods, none of which worked, because they all fail at one step or another when it tries to use symlinks, even if I’m using a prefix during ./configure of /home/myuser/local

I just tried it. There seems to be no networking.
nslookup does not work, so no addresses get resolved.
apt-get cannot find its repositories.
ssh to an ip numerical address does not properly send the password, so the connection is refused.

Some questions:
1. Is there a Linux file system somewhere? Where?
2. Can we call Linux functions from a Windows program (e.g., fork())?

Network Name Resolution: you will need to edit your /etc/resolv.conf file to point to a DNS server on your local network (probably your router’s IP address), I would say use something like google’s DNS server (8.8.8.8) but there is a further issue that prevents that (more on that in a little).
EG:
root@localhost:~# cat /etc/resolv.conf
nameserver 10.33.33.1

Once you have done that, you can at lease resolve IP addresses… but…
routing doesn’t work correctly. You can ssh to Linux/OSX machines that are on your network, but you will not be able to access any servers that are not in your subnet.
:: sigh ::
I was hop this would make my life easier, but I’ll have to wait a little longer.

As for your second question, I’m pretty sure they said that you cannot run commands from one environment in the other. Win32 can only invoke Win32, Linux can only invoke Linux. I think that the bash command you can run in cmd.exe is not actually bash, but a wrapper for wsl that auto launches bash.

Re. your questions:
1. Yes – cd / 🙂 We synthesize a Linux-compatible filesystem when running within Bash and mount your local NTFS drives under /mnt/… so you can still access all your normal files & folders too.
2. No – we don’t expose the Linux syscalls to Win32, but you shouldn’t need to anyhow since the syscalls just call through to Windows kernel routines anyhow, as do Win32 calls.

This is a very exciting subsystem! As others mentioned though, some Win32 Linux subsystem interop is key, otherwise this is not much better than a VM that mounted my host’s C:\ drive via SAMBA. Maybe you can have some special syscalls for calling CreateProcess on a Win32 app, and then have the subsystem properly convert between expected Win32 and Linux stdin/out pipes? Do you collaborate with upstream Linux kernel, e.g. so that they agree not to use syscall numbers that you allocate for such special purposes? You just need some special loader magic happen to tell apart an ELF and a PE executable. There are also some valid questions about how to handle Windows UNIX path conversions like MSYS2, or not do it like Cygwin.

You mentioned: “If you want a Bash-like command-line, but with access to Windows apps, tools, etc. then Cygwin is a better option since that’s a Win32 ported version of the GNU tools.”

Oh boy… Are you familiar with Cygwin or have you used it much? I have. It’s a great idea in theory that does terribly in real life. That’s why I’m excited about this new subsystem. There are some things you should know about Cygwin:

1. It heavily relies on undocumented behavior and APIs in Win32. For example, forking is extremely slow and unreliable and makes some undocumented assumptions. For example, it assumes that DLLs in the “forked” process will be based at the same address, which any Win32 programmer knows is not promised to happen. If this doesn’t happen, the fork fails. That’s the most famous dodgy example but there are more.

See the SO link for more, but the biggest problems I had with calling non-Cygwin Win32 apps from Cygwin is use of pipes. Cygwin does pipes differently than how cmd.exe does them, which causes some compatibility problems with some Win32 programs…. as in, every program ever written using Visual C++ CRT or .NET Framework System.Console class. Long story short (long version in above SO question), I ran into a problem with NETFX 4.0’s Console class: if the stdin pipe is overlapped then Console.Read* may erroneously block forever.

So basically you can’t call a NETFX 4.0 console EXE from Cygwin without custom building Cygwin with my patch, because upstream can’t be bothered to have an optional option. Last thing anybody wants to be doing is debugging guts of Cygwin just to invoke a NETFX .EXE!

Now we have entire products like “Git for Windows” which is based around Cygwin… I mean MSYS2 (which by the way, only exists because MSYS2 developers can’t communicate with upstream Cygwin developers: https://cygwin.com/ml/cygwin/2014-12/msg00155.html ). I bet 99% of people downloading Git for Windows don’t realize how flaky this product could be (i.e. don’t know what “fork” is, let alone how broken Cygwin’s version is).

Long term, in my opinion, one or both of these need to happen:

1. Cygwin could be replaced entirely by this new subsystem if you provide adequate Win32 Linux interop.

2. You collaborate with Cygwin upstream maintainers to:

2a. Remove use of undocumented Win32 behavior in Cygwin by providing native Win32 subsystem functions like fork. I guarantee the maintainers will be only too happy to do this!

2b. Get Cygwin working *properly* when invoking non-Cygwin Win32 apps, e.g. if they need any additional APIs for this to get the piping working right. But given their attitudes maybe they won’t care?

I am dying to try this out! I’ve opted to get the developer builds and I got the latest one that is supposed to contain the Ubuntu on Windows feature talked about in this article. I’ve followed all the steps to enable getting this feature, but the option to add it is missing. I was in the slow ring, but have changed it to fast since hearing about this. Hope to get it soon.

You’ll need to be on the Windows 10 Insiders fast-ring, and be running an x64 OS. You’ll then need to download the build 14316 released yesterday (April 6th 2016). It may take a little while to download, but it is on the way! 🙂

I read through some of the comments and saw a couple times people mention it, but the responses didn’t real address it or maybe I missed it. So if I’m writing a Python script say for Arduino how would I address the board? Should I write the script for Windows or Ubuntu? Will it depend on how I launch the file, whether i started python from powershell or bash?

Ultimately, if your Python script is targeted to run on an IoT device, and has no platform-specific dependencies, it should run fine on Linux or Windows 10 IoT on Arduino’s, Raspberry Pi’s, etc.

But if you’re talking about a Python script that runs locally to, for example, process some files before they’re deployed to a device, then you should be able to run fine on Bash or the Windows console, so long as you don’t depend on any platform-specific features.

This said, I’ve not tried deploying IoT code from Bash on Windows yet – be great to hear how you get on 🙂

As far as I understand, you implemented a new new subsystem for the OS. So, did you created a new flag for the executable files (PE Header) and updated the linkers (gcc, clang…) to target this new subsystem? Or did you updated the Windows loader to recognize and support the Linux ELF format?

I’m curious because in my opinion it’s a quite impressive engineering work, and also, because it impacts the way we are going to build code on this subsystem.

We’ve not updated the Windows loader to load and execute ELF binaries – this is why you cannot execute ELF binaries from within Windows. Currently, to run ELF binaries, you have to do so from within the Bash shell which is started by Bash.exe (part of the WSL) which knows how to spawn our new process and loader infrastructure.

Thanks for the details. Having the Windows loader recognize and load ELF files in a Linux subsystem would have been a crazy thing 🙂 So the term “subsystem” does not refer to the same concept as in POSIX or Win32 subsytems?
That would be nice if you write an article about how you are doing it 🙂

Why they kill Interix??? SFU/SUA was excelent. With it I can list or kill any system proces no matter sshd or svchost.exe. And it works wery well with AD auth. I have still installed Interix on my 2008 R2 machnes…

Without interact with Windows, for me WSL is still less usefull than Cygwin.

I (and many of us here at Microsoft) were big fans of Interix/SFU. But, at the time, very few customers used it.

However, times have changed and the world has moved. Linux is now a very popular target for developing and running open-source projects, and the ability to run Linux tools is essential to many developers, especially those working on web site/service projects.

The Interix codebase hasn’t been updated in many years and had several things that needed a significant overhaul to support some of our more modern and future-looking scenarios. So, we started down a new path which sets us up well for the future.

PowerShell is still BY FAR, the better command-line tool for administering, controlling and operating virtually every part of the Microsoft ecosystem (Windows, Hyper-V, SQL, Exchange, Azure etc.), but that doesn’t detract from the fact that dev’s often have significant challenges working on open-source projects on Windows.

We enabled Bash and Linux tools to run natively on Windows primarily to support the many developers who work on open-source projects that have hard dependencies on Linux binaries and/or behaviors.

Yes, you can fire-up Linux in VM’s, and use them successfully from your desktop via SSH, or the Virtual Machine Connection app, but the experience can be very lacking if you want, for example, to edit your source in Visual Studio on Windows, but build and run that code in Linux.

The ability to run a high-fidelity Bash experience on Windows allows developers to work on the same codebase side-by-side on the same machine, using the tools they prefer for various tasks in their workflow.

Accessing the power of Linux direct from Windows can be a powerful feature.
I have Windows 10 Pro 32-bit with build 14316 on a 64-bit desktop. I have “For developers” turned on. When I go to Windows Features, I do not see a listing for “Windows Subsystem for Linux”. And the command prompt does not recognize “bash”.

Is there some other way I can get this Linux Subsystem feature?

(Pre-answer to those who went brain dead when they saw 32-bit and are compelled to ask why, I use 32-bit because there are tens of thousands of computers that were sold at lower prices because retailers installed the 32-bit version of Windows instead of 64-bit.
While I no longer develop, I do assist others in troubleshooting what they already have. Those who are stuck with a free 32-bit upgrade are my biggest customers. And recommending they pay full price for an upgrade is the last answer I provide.)

We run an Oracle application that runs on Linux and need to be able to write ‘cron’ jobs that execute processes on Windows servers from time to time. While the shell is neat, for our use, we really needed something like the recently departed SFU er … SUA … er …

Telnet server still exists in 2012R2, but it doesn’t even support a secure connection.

Please consider adding some type of RSH connection to this tool, and it would be really handy.

@Rich, is there a way to ‘uninstall’ and ‘reinstall’ the windows store Ubuntu on windows package? Am trying this out for the use case of doing rails development. Installed bunch of stuff trying to get rails running. But would like to start again with a clean slate. 🙂

Can the bash terminal for windows run https://root.cern.ch/content/release-60416 ? I haven’t installed the bash terminal on this computer, since I don’t want to mess anything up. There is an Ubuntu binary distribution. Because this would be amazing.

Like many others I had a false joy, not being able to interact with Windows Applications make this not very usefull. I will stay with Cygwin and keep ssh-ing in the linux box when in need of a complete separated linux environnement…

Congrats on this potentially valuable new tool. I mostly live on the command-line (OS X/Linux) so I was very excited to install this preview build. Like others, I’d like the ability to run Windows code from a bash prompt. My particular scenario would be to ssh into my Windows box, edit code, then compile it with mingw32/64.

I, for one, am looking forward to this new development. As soon as it is available it will be installed on my machine. I cannot tell how many times I have run commands in the command prompt, only to realize that I typed the Linux/Unix variant rather than the Windows/DOS commands needed to do things on the system. To be able to run Linux commands on a Windows box would be a dream come true. I remember the old POSIX compatibility subsystem I used to install on Windows NT. I think this will surpass that by a milestone.

It would be nice is WINE could run on this subsystem, too. Will the Ubuntu subsystem be 32-bit? If so, will it be able to run 16-bit applications? I still have a few of those I have to put on a 32-bit Windows 10 VM in VMWare Player just to continue using them. I’d like to be able to run apps on WINE rather than in a Virtual Machine as I currently do. I’d rather shed as much third-party software between the hardware and software as I can and still be able to do my work and research, since using Hyper-V isn’t going to be an option on this machine because of lack of SLAT support.

Perhaps one way of solving interapplication communications would be to create a device (in the Linux world) that could connect to a windows application, say through named pipes or something. That way you could actually pipe directly from the bash to a windows application. You would also possibly be able to reach into some of the windows internals this way as mentioned below for both reading and writing datastreams or databits,.

This sounds like a fantastic resource, and something I would use on a daily basis. My main question is will this have support for X forwarding from a server or the ability to display gui’s from programmes run on Ubuntu. For example, if I am writing some python code and the code produces a graph with matplolib, will Ubuntu for Windows be able to display this, or can it only work with command-line text. Likewise, if I ssh into a linux server from Ubuntu for Windows, will I be able to display Gui’s for programmes running on the server? If not, is this planned in the future? I’m typically using a lot of open-source scientific software, which is almost exclusively written for linux (as is my own software). This software can usually be run successfully on Mac, but the windows versions either don’t exist, or lag behind. Ability to run gui’s in this manner would completely transfer this area and bring windows on a par with Mac.

Could we also do debian? I’d prefer it to ubuntu. Ubuntu sometimes breaks for no apparent reason, sometimes you have to type the same command three times for an entire process to complete. I’ve never noticed this mysterious issue in debian.

Does having bash also enable us to install kde and run it? Now that would be awesome.

Picking a flavour, and qt based applications are among the most desirable features for me. Any projections as to when this is going to be incorporated in existing windows 10 updates?

Hey Microsoft I’m so happy with that, but I’ve a suggestion, instead use any distribution of Linux, why don’t to use FreeBSD?
You’ll please the open source community and won’t have problems with licenses!
More freedom to your business model.

You need to first ask why they selected Ubuntu bash. I understand you want everything, but they must first be able to run one thing. Please watch the video on BUILD and you will see that their focus isn’t to be able to do everything that Linux does. There is a focus to running bash.

This sounds really cool, and I’m hitting refresh over and over to try to get the new bits to run this. I, too, see where it’s pretty neat, but I don’t know that it’s completely useful to me. What would be useful, however, is if this is made to work on Nanoserver down the road, and then we could potentially run Ubuntu and Windows containers side-by-side on the same hardware.

I develop Linuxbrew, a package manger for Linux derived from Homebrew, the package manager for Mac OS. Someone submitted a GitHub issue who was trying to run Linuxbrew on WSL. I’m unable to test/reproduce the issue because I don’t have access to a Windows device. Would it be possible to get either a loaner Windows 10 device or a license for Windows that I can run in a virtual machine? I’m also a grad student.

I currently use Cygwin on my desktop machine as part of my main Windows working environment, and also use a Linux VM on HyperV to run an actual Linux for some test cases, so I was very excited about this feature.

It sounds like a great job, but I expected a more complete and integrated environment, not just a plaything. These are some things I find missing:

1. Execution of Windows executables, of course (I didn’t try to install Wine, but I think it would be a little overkill). These are some Windows/PE exes I currently use on cygwin:
– “cmd /c start” to open documents or directories
– gvim, which is my default graphical-mode text editor
– java
– Beyond Compare
– Notepad, Word, Excel, etc.
– Visual Studio and its pack of command-line tools
– netsh to handling network settings from the command line
and a lot more…

2. More integration, mainly at the network level. Simple tools like “ping” or “traceroute” don’t work, which for me is a need. Besides, it would be great to handle Windows network settings from the command line through classical “ip” or “ifconfig” commands – or an equivalent (I currently do it from cygwin through netsh). It also would be great to view Windows processes by using “ps”, etc.

By now, I’ll need to stick with Cygwin and a Linux virtual machine on HyperV.

I’ve been using Linux via VMWare to handle my Linux servers for years, mainly using SSH and RSYNC. I tried CYGWIN briefly, but there were always directory and file permission problems. Linux on VMWare is slow to load, and slow to run.

Now, I’ve install this Ubuntu on Windows, and I love it. Imported all of my bash scripts, changed directory names, and all works like a charm. I love it.

I’ve encountered one problem that needs resolution: I set up several cron scripts in CRONTAB, but they don’t run (but they definitely run outside of CRONTAB). Is CRONTAB working in this beta version?

Hi,
I have already broken my WSL ; i did follow few instructions in the blog to reinstall however i am stuck with same issue; i keep receiving error 0x80070002

i deleted/renamed softwaredistribution download and datastore folders too and stop/start the OS update but nothing helped
here is the screenshot http://i.stack.imgur.com/gDxIW.jpg
badly need help to fix this

Hi,
I have already broken my WSL ;
I had issues with elinks package after i tried to enable javascript by editing a few code and installing some packages; when the elinks did not run i uninstalled since then trying to figure out what should be done to get back WSL back again
i did follow few instructions in the blog to reinstall however i am stuck with same issue; i keep receiving error 0x80070002

i deleted/renamed softwaredistribution download and datastore folders too and stop/start the OS update but nothing helped
here is the screenshot http://i.stack.imgur.com/gDxIW.jpg
badly need help to fix this

@Cupboard Love: That’s because you really _haven’t_ deleted the distribution, the lxrun command doesn’t delete the lxss directory. And it’s really hard to find since it has system/hidden attributes (it could also be virtualized, which would put it a different spot than you would expect.)

Here’s what I did: Get a copy of ‘Everything’ from ‘voidtools’. When Everything has finished scanning your drive, search for the correct ‘lxss’ directory and delete it. Then rerun ‘bash’.

Thanks for the tip @Mark Felt ; i tried to follow the instruction provided by you ; i was able to remove the lx folder from win32 and app/local folder however after that i figured that turn windows feature on or off went blank; i followed some instruction from other blogs but did not work

i m in no hurry to get bash back if i need to revert to previous version ; i can wait til next update; will i have to do a clean install or an update should solve my problem advice

(Background: from the mid-70’s to early 90’s – developing software/firmware in software/hardware companies; consulting from 90’s on typically in Windows-centric environments – providing custom solutions for integrating COTS products in client organisations.)

Came from a Unix background (that’s all there was back then) but have worked within Windows since the 80’s.

I have built tools for large (global) corporate and government clients using a mix of MKS tools and Windows tools for decades. Normally, somebody working in a Windows environment needs access to Windows tools. For example, I wrote many thousands of lines of sh scripts to invoke NetBackup tools which are all Windows .exe commands. Integrating the management of backup services within an organisation requires invoking native Windows utilities and interfaces and lots of 3rd party windows tools. The value of having Unix-derived tools is the incredible scripting power that entails. The MKS tools give a perfect balance of Unix utilities natively integrated within Windows.

You need the Unix tools for generic scripting and Windows tools for windows-specific services and interfaces.

One needs to distinguish the runtime interface from the utility interface. If I really need the Unix/Linux runtime interface, I am likely a Unix/Linux environment developer in which case I will have my own environments. On the other hand, everybody who scripts in Windows could benefit from the richness, stability, and consistency of the Unix utilities.

I have used Powershell as needed – the learning curve is steep. I believe its audience comprises Windows programmers (with minimal Unix exposure) wanting a higher level programming interface than C#/C++ with library calls. Ksh/CMD operate at a higher level than Powershell and addresses a much larger audience of admins and integrators who do need the lower level facilities.

Microsoft bought Interix many years ago to run within the old Posix environment – it provided an enclosed Unix’ish environment with compromised access to the Windows environment – it was not useful to many people. I fear this embedded Ubuntu environment will not fare much better.

Hay,
I’m just wondering, how is this better than MobaXterm?
Also, running apps from it would be helpful for me. Like on a Mac, you can install xquartz and then view graphs while remotely connected to a server, like so: http://apple.stackexchange.com/questions/103814/cant-plot-with-gnuplot-on-my-mac
This is really helpful in scientific computing, where you might have a large file that would be annoying to transfer to your desktop, so you’ll use a supercomputer to plot the data and XQuartz to visualize it. It would be nice if Windows could support something like this.
Also, I know there’s always Visual Studio, but will this work with compilers like gcc and g++? That might be nice for when you’re writing a small program and would rather not open up Visual Studio.

PyMOL is user-supported open-source software. Although some versions
are freely available, PyMOL is not in the public domain.

If PyMOL is helpful in your work or study, then please volunteer
support for our ongoing efforts to create open and affordable scientific
software by purchasing a PyMOL Maintenance and/or Support subscription.

More information can be found at “http://www.pymol.org”.

Enter “help” for a list of commands.
Enter “help ” for information on a specific command.

Thanks for the report, but as stated (repeatedly), we are not supporting GUI apps in this release: We’re entirely focused on delivering a solid command-line experience to enable developers to clone, build, test and run their systems locally. We are not supporting X GUI apps, nor production server workloads at this time.

I’m happy with bash on Windows, finally I can program in Ruby, pythom and elixir on Windows without headache, but as others have said the best would be to see the Bash being themain command line app for Windows users and Windows applications can be invoked by bash, and can communicate with the bash as in OSX, Microsoft can destroy Apple with this feature (in my opinion)

So if I understand well the linux kernel is not ported. So I suppose that we will still have to use third party drivers to have write/read access to our ExtFs partitions. So this is not Btrfs or XFS in Windows.

I really like this new bash for Windows. In the past, I had used Cygwin tools with good success, but occasionally I’ll want to run Linux binaries. Is there a way to access network drives or removable disks? /mnt only gives me my fixed hard disk c and d drives.

Is NFS supported? Also, I have a real live Linux partition accessible via ext3fsd. Can I access Linux binaries directly from there?

The time zone seems to be set at UTC instead of local time. Any way to change this?

Lastly, I’ve encountered a major crash! If I’m logged a VPN via Cisco AnyConnect, and then I use bash TCP/IP tools such as ssh or ping, Windows 10 blue screens, sometimes restarting itself and other times just hanging.

Just got this update today, been looking forward to it. Where is the best place to track issues and help inform development? My first stumbling block was getting screen up and running – respite creating /var/run/screen/ and changing the mode to 777 as required I still get fifo errors. Wondering if this has been raised as a bug which I can check up on?

My only concern is interoperability between the host and the Ubuntu, I (like many others) was also expecting to be able to run “shutdown -r now” and actually rebooting Windows.
Also, when using Vagrant or VMs with a shared folder in Windows, you can crash and burn your dev environment in just a heartbeat. I hope that this will not be the case with this new tool and that our own terminal is mature enough to reduce friction between the two of them and prevent errors like this: http://stackoverflow.com/questions/26155135/node-npm-windows-file-paths-are-too-long-to-install-packages

I can’t wait to try this thing out, I’m really hoping I can try my first real Windows Dev box this year.

I too am not finding the “Windows Subsystem for Linux” option within Turn Windows feature on or off. I have enabled Developer mode, signed up Insider Preview builds, and still nothing. What am I doing wrong?

I too am not finding the “Windows Subsystem for Linux” option within Turn Windows feature on or off. I have enabled Developer mode, signed up Insider Preview builds, and still nothing. What am I doing wrong?

I was thrilled about trying bash on NT, but it either needs to become a full API to allow Linux interoperability with NT or it is almost useless. It is simply too easy to use ssh (putty.exe and Xming.exe) to a local virtual machine or a networked *nix resource, and get full Linux. NT bash has ssh capability but not X forwarding (ssh -X) which allows GUI functionality between Windows and Linux.

Active Directory (Microsoft LDAP and Kerberos) is an extremely important Windows technology but unless this initiative with Canonical allows integration of two different shells on the NT kernel into Microsoft networking, little is to be gained. SMB shares and AD authentication from Linux is certainly possible but as of SAMBA 4, still rough and a bit insecure.

Running Perl on Windows was/is a pain, but Python and Node.js work well and generate transportable code. For that matter C# and C++.NET on mono are transportable. Most of the everyday bash tools like grep can be approximated in PowerShell without too much difficulty. Java is more or less interoperable for most developers as is aside from end-of-line conventions, case sensitivity, and directory separators – just as Perl is.

Given VM technology and the strong presence of Linux on IoT devices, Microsoft really has got some tough decisions to make. Windows 10 IoT boots using uBoot, an open source project so clearly there is some acceptance of interoperability. But this toe in the water bash on NT needs to become a real API, otherwise, it cannot compete with a plugin Linux machine (e.g. BeagleBone or raspberryPI) for basic development.

I do not envy Microsoft management having to make a decision to bridge the *nix – Windows divide. No easy answer but with Linux running on Azure and Windows 10 IoT struggling technically, keep up the good work.

I would like to know if it will be possible to use compiler tools (like GCC) in the Ubuntu Bash to compile software that will run natively on Windows. That’s really the most interesting part that I see on it, because the Cygwin/MinGW compilers cause many problems when trying to compile anything.

I would like to know, whether there will be any further updates, I mean the GUI apps are slow and buggy . And as mentioned I shouldn’t be running my server on it, but will it be possible in the future ? I mean at least for testing for localhost purposes?

Remember – we’re not supporting GUI tools at this time – we’re entirely focused on delivering a great command-line feature-set for now.

When it comes to server scenarios, you can run ssh, lighttpd, redis, mysql, etc. today, but you may see perf & config issues – there’s a reason this is currently a beta feature!

This said, we have not stopped working on Bash/WSL since finalizing Win10AU – the teams continue to crank on fixes, improvements, and new capabilities. Updates will continue over the coming months in Insiders builds, just as before.

I was able to install WSL successfully on build 14332 and use it for a couple of days. As of today, when I try to use it by starting bash at the command prompt I get error: 0x80070005. I see several references to this error code here relating to installing it, but no resolutions for it yet. Any update on this error and how to resolve it, work around it?

Do you have any plans to make uids and gid’s work? Many Linux applications won’t even run under root account (and needless to say, many more such applications are a security risk when run under root account), and as far as I can see (on a recent build) that chown does not change uids at all.

This is not about interoperabilty with Windows users/permission system, it’s about normal functioning of a Linux subsystem.

Not sure what are you referring to. In my case, Ubuntu install asked me for a username and password and then created a regular user (who is conveniently a sudoer) and all permissions and uid/gid seem to be working fine.

Very cool stuff, thank you very much.
I went a bit further and installed my typical dev toolbox – ssh, git, make, gcc, clang, cscope, vim, jq and python-pip (mostly for aws cli which also works) – all worked like a charm (had to run apt update once because the definitions were stale and led to non-existent server for some dependencies). So far so good. I also installed vnc4server, and it even started, but then i discovered that I do not know the IP address of the Ubuntu box, so I cannot connect.
ifconfig wouldn’t work because /proc/net/dev is missing – I assume, it’s a side-effect of a container-type deployment.
Hence the question – is this (lack of /proc/net/dev) a bug or a feature?
And also, how can I tell the IP address without running Wireshark on the host?
Thanks,
Ilya.

I have a few questions which I have in mind:
– How does the Home folder will work? It will be shared with C:\Users\[Username], or resides somewhere else?
– How does work if I try to upgrading my Ubuntu to the latest release? Can I update it to 16.04?
– `$ apt-get -y update && apt-get -y dist-upgrade` works like in regular Ubuntu?
– What if I trashing my installed Ubuntu on my system, like unwanted system file modifications or `rm -rf /*`? Can I restore it to the original state, before any modifications? Sooner or later you will install a lots of new tools and sometimes you just want to give a fresh start, like when you use a VM.

1) Your home folder is separate from your Windows home folder – we didn’t want your Windows config files colliding with your Linux config files.
2) We don’t currently support 16.04 – we’ve some work to do first
3) Yes – apt should work the same as in Ubuntu … because it is Ubuntu’s apt!
4) To fully remove your Ubuntu instance and start again, type the following in cmd/PowerShell:
lxrun /uninstall /full
…
lxrun /install

I don’t know how I became “LiveUser912” instead of my real name (changed it on my account settings, to no avail).

Anyhow, my comments after using Win10/Ubuntu for a month (or whatever, since it was released). I wanted to use it mainly for syncing to my servers. But when I run a bash script with lots of FTP or RSYNC comments, it always gets stuck on one line or another, every single time. It doesn’t seem to be related to any particular file type or size. If I can’t use it for this purpose, it is basically useless.

So lemme get this straight… The people want POSIX-compliant tools in Windows. The proposed solution by Microsoft and Canonical, is to run an implementation of the Linux kernel as a Windows program/service, so you can run Bash and the standard stuff you find in Ubuntu, isolated from the rest of the system. Microsoft and Canonical have brought us LINE. It’s not an emulator, it’s not a virtual machine, but instead it’s an OS running native on another OS.
Don’t get me wrong, that’s still a great thing, eliminating the system bloat of virtualization, but it’s just not the solution for the people who rejoiced when this was first announced.
And to put it simply, it’s not native. Linux is running natively on Windows, and Bash is running on Linux. Can we please just have Interix back? Cygwin is a pane in the glass.

Sounds great. E.G. I’d love to go grab the latest binary of Apache Zeppelin and be able to use its bin/zeppelin.sh with bash and have everything just work. However it doesn’t sound like it’s quite there yet unless you also setup the JDK again under the Linux on Windows.

An official standard UNIX emulation layer on Windows is much better than a mess of 3-16 mismatched ones. E.G. if you install git for Windows you get one msys env with bash and a mini vim and a little Perl, then install Github desktop and you get another msys that can’t share all the binaries, then install vim for Windows and you sort of get a couple more. Then some people use a few cygwin tools, maybe install gnu’s win32 coreutils or a non-cygwin Python and Perl version, and you start getting issues around one of them only working from the command shell with a poor terminal, but erroring out if run from either the Mintty git bash prompt or from within vim… Unfortunately this is another-way and not yet the-way.
Still very very exciting news.

They did have a Unix support story sadly it’s not one you want to hear, there Unix implimentation constantly dialed up Microsofts own servers to give away user info, it was called Unix for Windows and AT&T did a version of the KORN Shell for Windows which ironicly made ksh work better under Windex than it did on Linux! But then in hindsight Bash Shell was always a Microsoft invention with agressive backslashing instead of forward slashing and it’s really no surprise that a Bug in bash went undisclosed for YEARS… This is Microsoft we’re talking about, they dont inovate the EMBRACE – EXTEND & EXTINGUISH.

Ubuntu (Trusty) – You could hardly use those two words in the same sentance, does the Ubuntu Kernel still *cough* all it’s little misconfigured bugs to Kernel Oops (dot) org? Backdoors in Linux? No such thing assures the maintainers, but then you only have to look at how microsoft destroys its own government security of Kerberos for Windows and demolishes its own firewall leaving you with NETBIOS implimentations relying on outdated and misconifgured LM_Hash instead!

Bit-Locker – forensics anyone? Let’s not forget what happened to TrueCrypt where suddenly it became available for Windows only devices and lets not forget how UEFI and Wake On Lan magic packets now seem to be the norm in your Windows BIOS.

I have a question. I installed the bash but i have a problem with this. After the instalation i dont give root access only a normal user. How can i access to root user. (su need password but doesn’t work with my windows password) any solution to give me a root access. (this is my user ilyes@DESKTOP-C66S0MA:~$ <- but this is a normal user)

Yay! An nobody broaches the all important question: And how much does “Red-Mond” and Stevie wonder, expect to charge it’s end users for the privlidge of using Bash under (gag) Windows?

So to clarify they’re going to take there buggy all spying Windows 8 (oops) ten – I mean, bundle FOSS free open source software components into it whilst doing nothing about the baddly fragmenting file system known as NTFS, the total lack of any kind of decent corperate firewall and all awe inspiring way Windows handles memory and infect us all with it? I’ve always found it kind of fantastic how Microsoft gets away with trampling all over tech users rights, not to mention even more fantastic the way Linux and FOSS systems seem to cut through microsoft platforms oh and Android ones like Butter with the MSF – Metasploit tool kit!

Try fixing your buggy kernel implimentation and stop incorperating garbage from SELinux maintainers and listen to the grSecurity maintainers and then maybe youd have a product people would be interested in, but if its all about advertising and it generally is with there software model, no one will be interested in your lack of user privacy policy or your aggressive move into the Linux / BSD and Plan9 sphere of TRUSTED programming when your own platform is about as UNTRUSTED as they come!

I was excited by this development. I was expecting Windows to be on par with OS X, with the use of the bash command line. Is this a correct assumption or does Windows need to do more with changing the NT kernel to get a system similar to OS X?
I hope this is a serious endeavor and not just fluff.

This is a very serious endeavor for us, one which is resonating well with our developer community.
That said, while many things work well on Bash today, as we’ve stated clearly, this first release is an early beta release and there will be gaps that will cause some tools to fail. We’re continuing to work on Bash/WSL in the coming months too, improving the depth and breadth of our syscall implementation, so you’ll see continued improvements roll out in the coming months.
Also, since this is a technology to allow developers to clone, edit, build, test, and run their systems locally, this is not a technology upon which to run production workloads. There are plenty of great options for running *NIX production workloads from dedicated *NIX machines, VM’s (locally and in the cloud), Docker, etc.

Seems to me the simplest way to make calls between the systems would be to get the openssh port for windows completed. With ssh you could send commands back and forth. Not the best method, but since the work is already being done, it should be feasible at some point. In that regard, it would be nice if you had the option to create a separate dedicated virtual network interface for the linux subsystem.

Does “Bash Ubuntu on Windows” have any parameter to start automatically Linux command on open? For example, I can create custom shortcut to run “Bash Ubuntu on Windows” with a parameter to start apache web server.

HOWEVER, note that bash will close after completing the requested command – if no other bash console is running, Windows will terminate the bash process, closing Apache.
Because of this, we recommend opening bash and calling a script to start the services you want to run in the background instead.

I installed bash, played around a bit, got my hopes up. Went to run an existing nodejs project I have and it won’t do it. In fact it won’t run Node at all unless I invoke it with a different name (nodejs rather than node). It says that the path to node is not in the PATH env variable but if i run the command nodejs it works. To its credit, the version of VI it comes with has parenthesis highlighting which is great. Also to its credit, a very simple “hello world” node project worked. The problem comes when you try to use a package which references node, like for instance webpack or http-server. I would have to change the webpack and http-server source code to invoke “nodejs” rather than “node,” or set up some kind of symlink for “node” to be “nodejs.”

The shell is also case-sensitive which is a huge nuissance. It won’t autocomplete “cd docu” to “cd Documents”

I really hope Microsoft continues in this direction but in its current state, this bash is not that useful. If I had the time and mental bandwidth to find workarounds for random stuff I want to do, I’d just be using linux rather than windows anyway.

Hey, you guys rock! Just got the latest update and here we go – tmux and xterm run, so does :! in vim – awesome! One more to go – screen still would not run due to lack of write permission for non-root on /run directory.
Keep up the good work!

folks this is exciting stuff….I just fired it up on a brand new laptop. I am very familiar with Ubuntu and Windows, so, looking forward to seeing the integration in action.
I’ve used stuff like Cygwin for years. Having native bash and openssh, etc, will be interesting.
So far I’m seeing a few things like hostname resolution issues and some strangeness with RPC mapping, stuff like that. No complaints – I know its a beta – and if I figure out what’s up I’ll post here again, or, if you like, I can put in a bug report, just let me know. 🙂 -S

Ah ha! I ran with UAC bypassed, and things are running a little smoother. For example, ping works correctly now. My question from here is, how does this module/vm/container work? Is it a VM? Is it a container? Is there any kind of whitepaper or doc on how it was screwed together on MSDN? I’m mostly curious.

I’m a software developer who has avoided Windows 10, and didn’t know about the Bash feature until just now. Because of this article, I’ve decided to re-install Windows 10 and give it another try. It’s only one data point about a developer switching to Win10 because of new friendliness toward Bash prompts, but it’s a solid data point, so I’m guessing that the developers of the feature will want to know.

For me as a researcher/prototyper in ML, compute vision, and computer graphics. I have to say that this is a really great thing. Even though there are some cons, I have to say you that this is what I was praying for windows as I can run linux-only stuff (theano, keras, tensor flow, and more that other people do in python…) – so no need for virtual machine or other machine with linux.

As some comments below mentioned, it will be cool if windows apps could directly execute scripts in linux-bash and vice verse, but I understand that this could be difficult and could break many things Anyway, it is great what you do! Looking forward when it will be aveliable not only in the Insider.

Again, as other collegues agreed with me, it is really cool feature! Really cool.
Thank you!

You can call bash scripts from Windows right now by calling, for example, “bash -c “echo ‘Hello'” from cmd/PowerShell/etc. However, you can’t currently grab the output of Bash from Windows – that’s something we’re working on for a future release.

I am windows insider, I have checked the beta linux from the setting of system software and also run lxss.exe with /install. Script worked, downloaded package from windows store and started installing. Problem is that after let’s say 2 min of extensive disk use starts bash application which I monitor through taskmgr. Problem is – bash can run even 1 h and doesn’t install the ubuntu bash on my system. I have removed all files via lxss.exe /uninstall /full and tried again but the same problem. Anyone can help me? I have never reached moment when I have to provide username and password.

Fabulous tool! I love it! In an hour I had Ruby 2.2/ImageMagick/prawn/mysql2 all running… The only change I had to make in any configuration or source file was “127.0.0.1” instead of “localhost” so the Linux client could connect to the Windows MySQL server. Terrific job, great tool, thanks! I’ll be using it every working day.

I am so intensely happy to see this. I have been a UNIX/Cygwin user since the late 80s, and a Cygwin user since essentially Cygwin was publicly available. Microsoft has really changed their tune towards standards, open source and interoperability. Thank you.

Hi there,
I was hoping to replace my cygwin installation with the ubuntu shell.
So far it looks good. However, how do I access my network drives from the ubuntu shell?
With cygwin I just cd to /cygdrive//.
How do I do that in Windows from within bash?

Except the copy-paste function (which you said is coming), i’d like to mount other partitions.

I have an encrypted partition, created with veracrypt, where I store all my clients’ stuff. I’d like to cd directly there and work on the scripts instead of having to move them to my documents, do the testing and then, at the end of the day move them back.

I’m not able to run Java 8 by Oracle nor Openjdk8. Openjdk8 simply stops installing, Java process hangs (30% CPU) in Task Manager and Java by Oracle installed without issues but when I run “java -version” or “javac -version” it hangs. I needed to do a command add-apt-repository to get these versions because Ubuntu 14.04 has old Java version 7.

Amateur WSL – Bash user. Interested in cool stuff I can do with WSL that I can’t do in Windows 10. I am not a developer. I’m fairly proficient in Python. I don’t care about games or managing a server (already have that). All I see on the forums that aren’t dev are games, server mgt, and dev tools. Any advice?

I’d like access to the PC’s serial ports. One use I have for Linux is to run multiple serial measurement devices. I can’t use VirtualBox effectively because, while it can connect to up to four serial devices, it’s too slow for my use. Bash on Windows should have the speed I need to access the devices. It would save me from having to have two machines, one dedicated to running the serial ports and one for office work.

There seems to be a big flow in this Linux sub system. Being an engineer one of the most frequent tasks I do is to SSH into my development boxes using SSH Keys. The Linux subsystem does not let me set the 400 permission on my private key, and I am never able to change it to anything other than 644. This is a major problem. I looked up the Bash on Windows GitHub page and they state that permissions have to be configured using Windows Security. I tried that it doesn’t work either. This is one reason I am not able to use the Bash on windows. Did anyone else have this problem? How was it addressed?

I have been using the bash on Ubuntu on Windows on Lenovo G510 since the release but I have some problems to deal with my hardware stuff such like turn on the network adapter and so on.
so please help me to gain access my network adapters via the bash on windows

Hi Guys,
I tried to install Ubuntu app from the store, it went ok but I was not able to see the app in my app list. After I recognized I had not yet activated the optional feature for WSL thus I did so, restarted, but still no trace of the Ubuntu app. Now have not the app but if I open the windows store to get it, I do not have any more the option for installing it (it is like it was already installed). What can I do?!?!?

First of all , I am an insider and running win10 pro/32bit (based for 64bit) . I can not say that I am a developer, but trying my best to find solutions. I have NetBeans 8.2, I cloned Ubuntu-64 and ran one project on NB. (Node.js).lastly ,I downloaded git for windows and I have now a Bash command, a CMD command and a GUI . I did nothing since then and looking for advice to proceed or not with git commands . That was all and thanks for any help from your side !!