In this build, you can natively run Bash in Windows as announced last week at Build 2016. To do this, you first need to turn on Developer Mode via Settings > Update & security > For developers. Then search for “Windows Features” and choose “Turn Windows features on or off†and enable Windows Subsystem for Linux (Beta). To get Bash installed, open Command Prompt and type “bash”.
I’m really curious to find out what fans of Bash and Linux command line tools think of this after actually using it.
Dev Resources come and go.
No developer in her or his senses will burn the few remaining ships, not anymore. [MS is starting to extend a hand to those left behind].
This level of commitment is unheard of.
Should Devs leverage on MS? Humble point of view is Yes. [Just don’t invert too much time or mind share on MS specificities].
“Windows subsystem for linux” or “WiSL”, pronounced “weasel”
But other than that, now I almost look forward to receiving a win10 machine at work in about 4-5 years from now to check this out with.
You probably need a better job
It’s a quite clever system, and mostly “seems to work” on quick poking
A few rough edges I noticed playing with it so far:
* bash dies with a vague hex error if the console window is in ‘legacy’ mode, which apparently mine was.
* I’m having a failure building LLVM/clang… testing to see if I can use the Linux build of emscripten for a project that doesn’t easily build on Windows yet due to autotools and stuff). Not sure what’s actually failing there yet (it compiles a lot of stuff, then dies generating llvm-lib). Most people probably don’t need to build LLVM though.
Eventually when I get to building *my* project we’ll see if it works. 
* symlinks aren’t currently supported (NTFS has symlinks and also directory-symlink-like ‘junctions’ but you can’t read them from a Linux binary; they appear in the directory listing but aren’t openable/statable). This may trip up some workflows that rely on creating symlinks.
* somehow DNS resolution broke while I was running my first ‘apt-get install’. I had to manually edit resolv.conf…
* probably not ideal for running ‘real’ servers — there’s not a persistent init process or upstart/systemd/whatever they have this week. Running one-off servers like a node web server straight from CLI should work though.
* the Linux emulation layer tells things you’re “root”
But it’s running under your regular Windows user, as far as I can tell.
* Linux processes don’t seem to appear in the Windows Task Manager. Corollary: ‘top’ doesn’t display anything and messes up the state of the the console.
* You can run GUI programs using an external X11 server (I didn’t have time to set one up in Windows so launched XQuartz on Mac OS outside the VM). However gnome apps seem a bit flaky (needs dbus or something?) and launching an xterm doesn’t work (some ptys problem).
Ah, another thing — it doesn’t seem to work to launch a particular Linux command straight from the Windows cli; eg ‘bash vi’ errors out instead of launching vi:
C:\Users\brion>bash vi
/usr/bin/vi: /usr/bin/vi: cannot execute binary file
C:\Users\brion>bash
root@localhost:/mnt/c/Users/brion#
If this could be fixed, and piping data to cli programs over stdin/out/err worked, that would be super awesome.
Wait, that’s cause I’m a dumbass.
bash -c vi
works
*headdesk*
…but piping “bash -c ‘echo hello’ > barf.txt” gives me the hex error again that I got from ‘legacy console’.
Well, this is a developer cycle. Considering the sheer magnitude of the steering, still this is very good news. Thanks, Brion
That’s a nice list you have right there. I’m especially surprised that X11 forwarding worked. I’m going to have to give that a try.
They did mention that top doesn’t work, it seems it uses an unimplemented syscall or does it in a way that hasn’t been implemented properly.
I co-wrote a small article about my experience with it – https://www.slightfuture.com/how-to/x-on-wsl . In short, the X forwarding works fairly well, but firefox dies (some multithreading thing in xcb?), no terminals nor xemacs work (because they haven’t implemented ptys properly yet), and dbus doesn’t work (taking gnome and kde down with it) because named pipes don’t seem to work either. You could fire up vim-athena mode and use that to edit your windows files, though. (Or vim-gtk, but that only accepted keyboard/mouse input every third or so time I launched it.)
In good news, kill -9 seems to instantly kill even the deadest linux-side processes, so there are limits to how badly you can wedge things. Oh, and while I mention that gdb fails, at least strace works.
Edited 2016-04-11 11:07 UTC
It seems this feature is not yet available to everyone. Even several members of the Windows Insider program are nto able to test bash running on Windows.
http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insi…
Yeah, that’s a general problem with Windows Insider program and Windows Update being kinda flaky with delivering the latest builds. Very frustrating.
For longtime Cygwin users (or one of the many other *nix tools ports), I’d say that’s a non-event.
Your cygwin compiled linux utilities I believe will not run natively on Windows, unless you run it under the Cygwin environment. This is in the sense like you are having java executables, wherein it will not run unless you install the JRE.
Calling this a non-event(if I understood the term non-event) is i think wrong. Because the ones that is running in Windows is Native unaltered version of the Linux binaries, therefore this is a major event for all people specially you since you are using Cygwin.
Edited 2016-04-10 06:03 UTC
Interesting idea. Kind of reminds me of Cooperative Linux:
http://www.colinux.org
https://en.wikipedia.org/wiki/Cooperative_Linux
In a nutshell, it’s Linux running as a Windows process, but has been unmaintained for a couple of years.
A thought does come to mind.
Why?
Then of course my mind tends to wonder …. Thinking about things like, if that works why not try cleaning the bathroom with a tooth brush??
Can I install Linux backup script to backup my Linux stuff under windows?
… And other logical conundrums.
PS: Its dead Jim.
One REALLY annoying issue I’ve had as a windows world developer is that when I have to use tools that have come from a *nix background, generally have issues on windows.
Last time I used it, Ruby was horrible on windows. It was far better to use a Virtual Machine and shared folders and SSH port redirection blah blah to get it to make it work, or you could run your dev environment on a VM.
Node’s NPM used to cause issues with windows paths > 255 characters, which I’m assuming is because they’re using a library that still uses the old ANSI APIs.
So what Windows Subsystem for Linux provides is the ability to run elf binaries on windows, in a similar sense to how Wine runs PE binaries.
In practice, apt-get install ruby gets you a version of ruby that *just works*, and you can go to /mnt/c/dev/myrubyproject and run your project.
ports opened will be accessible from localhost:port so in theory, the development experience should be a lot nicer.
I do like using apt-get for stuff as opposed to downloading and running installers.
I think it’s a nice move on their part for people who write cross platform software.
I’ve run into that PITA 255 characters limit multiple times in Windows 8.1 when using Explorer to copy files, extract Android SDK etc, so Microsoft is using the old API even themselves. I don’t know if this is fixed in Windows 10 – I’ve never even seen it live.
I’m fed up with these “almost linux” tools and environments so I just run Ubuntu in VirtualBox if I’m using a Windows machine.
Edited 2016-04-11 08:24 UTC
I agree. Even better is running Linux on the metal and a throw away Windows image in a VM.
I used a KVM switch. F_(* with VM.