It isn't clear how much people can appreciate this sort of thing without context. Back in the mid 2000's I was at a very high level Microsoft Developer event and got to ask about waning support for command line tools.

People of a certain age remembered well the power and simplicity of using DOS and its "console" to effectively develop code and debug, even without typing 'win' to get into "GUI mode".

But at this event a very senior engineer/architect in the Windows group (no longer with Microsoft) responded to my question of command line support with a very snarky response which was something along the lines of "It is called Windows not relic from the 70's so no, we really don't care if you can't use it like a time sharing system any more." And that was the way it was, anything you could do on the command line you could do in a GUI window with radio buttons and various text boxes.

And what was why I switched to MacOS as my daily driver because my personal style had me so much more productive in "terminal" mode than in "gui" mode, I preferred it.

Now you have Microsoft investing real time and effort to create credible command line type tools in their system and it is a remarkably good thing. I use WLS every day and its getting better and better. I have suggested they implement a local network service equivalent of the USB over Ethernet service so that you can easily share USB devices between the Windows side and the Linux side, the up coming visual fixes will address many of the minor annoyances. That is a really huge shift for Microsoft.

It's funny you mention switching from Windows to MacOS for the command line tools. I booted up a pre-NeXT Mac (an iBook with OS9) the other day, and was blown away to learn that there is no terminal at all! How quickly things changed after that.

Absolutely. My background was that I was Sun for years and on a "workstation" the most common window open for a software developer was an xterm not some IDE. That said, for people who "grew up" knowing nothing but visual studio and delphi, telling them that everything they are trying to do is easily done in the command line doesn't resonate.

Even though I am a huge command-line fan, I am not sure that "everything they are trying to do [in an IDE] is easily done in the command line" is entirely true ;)

While one can do at least as much, if not more, via a variety of command-line tools, the integrated build & debug workflow of a good IDE is invaluable to many. Esp. for those for whom learning a multitude of command-line tools, and syntaxes to drive gdb, profilers, etc. as a little costly/cumbersome.

ISTR from my days when I was a primary school kid playing around with my grandmother's Mac running System 7 that there were some (fairly lame) third party tools that attempted to implement a DOS-style CLI.

> - Visual Studio can compile with GNU/Linux C/C++ tools, gdb, linker etc

First VS Core, now VS proper. Impressive!

(going back to my ddd window on Linux, crying a bit inside).

A properly configured and well-curated collection of packages will yield an exceptional experience using emacs - if you're into that kind of thing. Add in some custom elisp and you're well on your way to a fully customizable development environment.

Are you talking about proper, legit Intellisense in Emacs? If so, I'm sold. More details?

I've been playing with NetBeans and it seems like a fairly reasonable C++ environment.

CLion is pretty spiffy IMO, though it uses CMake as the underlying build tool which may or may-not be your thing (I prefer scons.. but nothing's perfect).

KDevelop is also a very good C++ IDE for Linux.

It is quite good, as it is the basis of Solaris IDE, just some features are missing.

Re: Elixir

The Erlang/OTP 19.x releases are still broken because of some missing system calls. They seem to have an incoming fix though: https://github.com/Microsoft/BashOnWindows/issues/613

It's great that they keep open conversations like this for issue tracking and hopefully April will be working 100% by then.

For this reason, whenever I try to develop anything on Windows, especially systems related stuff, I will do so in a VM. I may develop a test suite and try running it on Windows, but the Windows Linux Subsystem will never be reliable to me, until it aims to guarantee 100% compatibly.

Bash and Windows Subsystem for Linux is a band-aid solution for a fundamental problem for Microsoft: Linux tooling and kernel are IT industry standards.

People have been developing on OS X outside a VM for a while now, and OS X is most definitely not linux. If they can get WSL to be as linuxy as OS X (and arguably it's already close), Windows will be as good a dev platform for linux development as OS X.

But they really need to fix notepad so it supports unix style line endings. That part of the demo was a bit embarrassing.

WSL is more Linuxy than macOS, it implements the Linux syscall interface rather than Darwin's.

I agree with this. OS X is a flavor of BSD. I've learned that it's often more helpful to search for "<thing I want to do> bash BSD" than it is to search for "<thing I want to do> bash OS X".

Making "Winbuntu" a fully compatible Ubuntu sounds like a really lofty goal, especially when it comes to things that expect a Linux file system.

I guess for me, it's easier to reason about Linux in a VM (or maybe a container), with all the limitations of that approach, than it is to wonder what surprise might occur as a result of trying to run something on Winbuntu. At some point maybe that will shift. It's not like VMs are exactly like bare metal.

Keeping trying hard Microsoft! I like Winbuntu enough that I bought a Windows 10 laptop just to play with it! Emphasis on play, not seriously use.

I've been using WSL since it was released to the fast insider ring. It's pretty slick. There have been some warts and growing pains, but the team has been very responsive to bug reports. I've seen responses as quickly as 2 public build cycles (about a week) to get a fix for an issue reported on their github site.

I love watching people developing on OS X, targeting Linux, without proper tests forgetting that Linux's FS's are by default case-sensitive in regards to file names, and completely forgetting that OS-X is case-insensitive, by default (and recommended to remain so, because most OS-X software is not developed with case-sensitive file-system awareness.)

>OS-X is case-insensitive, by default (and recommended to remain so, because most OS-X software is not developed with case-sensitive file-system awareness.)

A few years back, following my previous laptop which had been a flimsy Acer running Ubuntu which became unusable following malfunction of the fan, I was looking for a more sturdy laptop and ended up buying a mid-2012 15" MacBook Pro which came with OS X Mountain Lion I think it was. Being used to case-sensitivity from various Linux distros and on my FreeBSD servers, I decided to enable case-sensitivity for the system drive. That turned out to be quite a mistake indeed. Several pieces of software were unable to find the files they needed, so I ended up reinstalling the whole system shortly after, this time without case-sensitivity.

Following that I had a hardware problem that the Apple authorized repairshops I went to were unable to fix three times in a row so I ended up demanding a refund (Norwegian customer protection laws are good in this regard), and while I still think OS X is an impressive system I lost a bit of my respect for Apple after that experience. (I enjoy my iPod touch though.) Anyway, the reason I mention this is just to say, I don't know if case-sensitivity remains problematic in macOS. I find it highly likely that it still is though.

Can't wait to run docker in this. Will save me countless development hours.

I was already a fan of colinux back then but this has te potential of being infinitely better.

You can actually manage/control Docker for Windows (upon which you can run Windows & Linux containers) from your Docker client running in Bash (or Windows) on the same box.

Inception ... noitpecnI ;)

They are for one part of the tech industry (which I count myself in) but it's pretty obvious that for many others, Microsoft-based tech (which now runs everywhere) is a standard. Why not persue both?

Why wouldn't getting as close to 100% compatibility as possible be the aim? WSL is currently beta. The installation documentation has a big warning at the top that functionality is currently incomplete.

All I can say is that the first two things I tried on the Windows Linux Subsystem didn't work, mainly running Elixir and Debootstrap. It's okay that they aren't (yet?) supported, but something that looks & smells like Ubuntu, yet isn't, doesn't inspire confidence that it can be trusted to act like Ubuntu.

An alternative approach would be to call it Winbuntu, Winux, or simply Ubuntu for <windows subsystem architecture>. Then aggressively maintain a list of known compatibility issues, and stay on top of fixing them. Maybe even open source it?! A close sourced, not-quite-what-I-wanted solution is simply less interesting to me.

I'm not sure a public-facing curated list of specific compatibility issues would be practical at this stage of the project's life; it's changing fairly rapidly. FWIW, the bug tracker is public, and the team seems to be fairly responsive; a UPX Compression bug I ran into was tagged fixinbound within a couple weeks. https://github.com/Microsoft/BashOnWindows

The speed at which they can push new builds to people who aren't on Windows Insider is a bit unfortunate, though.

> All I can say is that the first two things I tried on the Windows Linux Subsystem didn't work, mainly running Elixir and Debootstrap. It's okay that they aren't (yet?) supported, but something that looks & smells like Ubuntu, yet isn't, doesn't inspire confidence that it can be trusted to act like Ubuntu.

You need to handle this anyways, as it's unlikely that your target deploy platform will always be ubuntu. In any case, you can just use docker like most OSX folks do now.

I'm not familiar with Elixir or Debootstrap (I'm guessing web-oriented)? But, I've had great success with using WSL for C++ oriented projects, building with both g++ & clang. Only issue in that regard I've had is that the emulated syscalls cannot currently enumerate ethernet devices. The calls are implemented, but fail at runtime currently. I've not yet filed a bug report, because I don't know how it should perform.

You should be able to enumerate network connections on recent Insider builds ... or on Creators Update when it arrives in ... well ... "Soon™" :)

I don't think they can open source WSL in any useful capacity because it's signed as part of the kernel itself - afaict this is also why an update to WSL is an update to the Windows build itself.

> - You can launch Windows apps from bash.

So I can basically do `code .` from inside bash and it will open VS Code in the linux sub-system folder? That's amazing!

Almost. `code.exe .` will do what you expect IF you are in a folder that's visible from the Windows side. If you're in a WSL folder, the Windows program will be run in C:\Windows\System32.

It has worked well for me to make a symlink under ~ to /mnt/c/Users/myaccount/, and that way anything under that symlinked folder is visible to WSL and Windows programs.

Hi - yes, we register the '.exe' extension with binfmt that then triggers WSL whenever a .exe is launched, allowing us to go find and spawn the requested Win32 process.

If you just want to type `code <filespec>` (without the .exe), then you can create an alias that resolves to code.exe.

Same for Notepad, etc. :)

(HN: bitcrazed is Rich, the person presenting in the video)

Hey Rich, can you (or colleagues) tell us any news on console? I get the vibe from Michael Niksa back in August [1] [2] there's a big changes happening that will fix readline-type stuff and I'd love to know more about this - I use ConEmu / Win32 SSH on Windows and it, was well as bash, seem to occasionally suffer from terminal-corrupting weirdnesses.

I'd love to know more about the causes, the fixes, whether the fixes will make it into Creators Update, etc.

[1] https://github.com/Microsoft/BashOnWindows/issues/111#issuec...

[2] https://github.com/Microsoft/BashOnWindows/issues/111#issuec...

Yes, we're essentially giving the Windows Console its biggest overhaul in > 30 years!

It's important to remember that the Console was one of the first things Cutler & team implemented when they started NT itself, and it's been updated, patched, partially-enhanced and modified quite a few times in the last 30+ years! ;)

We're in the process of modularizing much of the Console's internals, replacing particularly archaic parts with shiny new modern C++ collections, etc., removing unnecessary cruft, etc. ... while trying not to break anyone!

Much of the work we're doing right now will result in Maximus5 & the Console2 / ConsoleZ / etc. teams having to jump through far fewer hoops to implement decent terminals on Windows.

And while we're doing this, we're also enhancing the console to support *NIX VT sequences, adding 24-bit color, etc., working with several other teams around Microsoft who need Console changes to make their things work.

This week, we are planning & building features for the NEXT OS release!

As you can imagine, it takes considerable effort and care to do this and we've got a great team with Michael, Paul, Mike2 & Austin beavering away as I type.

Actually; small lie - Niksa is on vacation this week re-charging his fuel cells before I chain him to his desk again ;)

We'll be writing a series of blog posts in the coming weeks, summarizing what's new in Bash & Console in Creators Update, and will have some cool stuff to show off at Build 2017!

I'll also be speaking at OSCON 2017 in Austin (same week as Build!!), so stop-by if you're in TX and want to chat about Bash / Console :)

https://conferences.oreilly.com/oscon/oscon-tx/public/schedu...

WSL is great, I use it every day and am very much looking forward to the next update.

Regarding future work, are there any plans to make the emulated Linux filesystem usable in the rest of Windows e.g. via a drive mapping?

Thanks and glad you like it so far ;)

We are keen to smooth out some of the filesystem interop challenges. There's a reason we've not yet removed the Beta label ;)

I'm a big fan of this new feature, enough that I wrote and released some open source code to launch applications before this was possible. Mine's a hack, pure and simple but it worked to fill in the gap but I'm glad to not need it anymore. Thanks! https://github.com/jaegerpicker/Rockhopper

Would I be able to setup Linux environment in VS? i.e. would I be able to include and write POSIX application with this update?

Did you watch the video? ;) Take a look at Visual C++ for Linux: https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-...

Yes, I did, and it didn't answer my question, but the blog post does. Thanks.

In the video, my demo was to take a POSIX C++ application and deploy it to a local WSL instance, built it, run it and debug it ... from VS.

This is actually the (previously) missing feature that was preventing me from fully diving into Win10 + Bash.. very happy to see this

I was under the impression that only linux sub-system applications should be modifying files inside the linux sub-system.

For example, using windows explorer to edit linux sub-system files would be a big no-no.

Yes, that is the guidance we're giving right now. See my post on this subject for more background: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n...

However, it's fine to modify files stored in your Windows filesystem from within Bash, so if you were in `/mnt/c/dev/project/` and launched `code.exe ./`, Code would open the current (Windows-accessible) folder.

First, I switched from OSX to Windows b/c WSL made it possible.

There is some weirdness with the recommended file system sharing. Git on WSL sees files as modified after they have been checked in from Windows. It means I either use Git from the IDE or from the terminal, but not both.

Excited to see how this continues to improve.

Great to hear - welcome to the party! :)

What you're seeing with git is likely to be caused by line ending differences. You've probably got "Convert line endings to Windows" configured in your Git on Windows, but "Checkout Linux line endings on Linux". Either way, both should match otherwise all your files will look different because ... well ... they will be ;)

Just for reference, I've been doing this for a few months now. I'm not sure what's changed, but you'll need ubuntu 16 (you can uninstall 14 and reinstall WSL to get it) in WSL to do it.

You don't HAVE to nuke & reinstall your Linux environment to get up to 16.04 - we also support in-place upgrades too ... so long as you're running a Windows Insider build >= 14951

HTH

Are you running the fast ring build?

EDIT: Actually, since I am doing that as well, I just tested it. And yes, it all works!

Cygwin has its own ANSI/VT100 emulation which is translated to Console API calls.

In the Cygnal project (http://www.kylheku.com/cygnal) I made a few fixes to this code.

With Cygnal you can write a terminal-oriented application using termios and VT100 escape sequences (or a library like ncurses if you wish). You just package it with the cygnal DLL, and any other DLL's. It will run fine in the console window.

For a demo of this, download the Windows installer for the TXR language.

https://bintray.com/kazinator/Binaries/TXR/txr-169

The txr.exe executable happily runs out of the cmd.exe console window with history, multi-line editing, etc. There is not a shred of Win32 code in TXR: it's just (a much enhanced fork of) the Linenoise library which uses termios and ANSI codes. Not a single #ifdef WIN32 in there.

Wow those are some pretty significant updates!

I've loved the idea of bash-on-windows but it was missing just enough that it wasn't worth it moving away from my current love affair with the "git bash" system I'm using.

With these changes, it looks like I'll be jumping ship when it comes to stable!

Great work to everyone involved!

Agreed... I tried it for about a day, then went back to git bash. Will probably give it a try again after it goes to release. For now, I've been sshing into a linux vm, and using samba/cifs to mount my linux ~/ so I can edit in windows, but better integration would be nice.

Is iterating over network interfaces possible? IIRC that was causing a lot of issues with local nodejs dev servers

Yeah it works.

I can finally ping, do ifconfig etc.

Even htop runs. I am amazed! http://imgur.com/7P2J64h

This alone made WSL way more useful for me. Only thing that's missing now is traceroute.

We're working on traceroute for a future release. In the meantime, you can run `tracert.exe <ip>` from within Bash which will invoke the Windows trace-route command-line tool to do the same thing ;)

This was added to the fast ring builds in December. Not sure of the timeline to get it out into stable, but it definitely was a big deal to get.

On their blog they state that raw sockets (ping), ip address / ip route will work.

Still some work there though. Traceroute errors with: setsockopt IP_MTU_DISCOVER: Protocol not available

Yeah, to be clear here: We worked with the networking team to enable Linux Ping to open a raw socket, but we've not enabled carte blanche raw-socket support for all Linux processes.

We are, however, continuing to work on solving these and several other networking issues to close the gap in our networking support.

As a work-around, you could always call Windows' tracert.exe via the interop feature ;)

An if you're just using standard sockets technologies (e.g. HTTP, TLS, FTP, SSH, etc.) all should be good.

Any chance we'll see a first-party X11 server at some point? XMing, VCXsrv, and Cygwin/X all have some warts when it comes to stuff like windows previewing, copy/paste, acceleration, and fonts. OS X has shipped with an optional X11 server forever, and it would be great to see that feature parity in Windows.

No plans at this time; we're focusing entirely on command-line tools & scenarios right now. Besides, there are plenty of X Servers out there, no?

On the fast ring Go 1.8 and Haskell are running okay as well as inotify working.

Sorry for being dense but how is this better than running seamless window Linux under vmware? With that I can also access shared files, etc.

It's less overhead and better integrated into the system as a whole. After all a VM is still a separate entity in its own environment. WSL is jumping over the fence and runs Linux stuff in a Windows environment.

Think of it the other way. Why would you use wine if you could just run Windows in a VM? :)

Why someone might use Wine is that it's free software. That's about it.

I think the point that parent commenter tried to make is actually that one might use Wine instead of VM because Wine has less overhead.

> less overhead

is it really? last time I read tests WSL was slower than VMs

I don't know if I would call it better or worse, it's more about preferred workflow. I'm typing this on a MBP and I have a fleet of VMs specifically because I'm tired of playing the platform game. I can configure a VM specific to an app's needs faster than hosing my host OS with a very specific configuration that may not match production environments. Even with version managers like rvm or nvm/n there is just a lot to get wrong. It may be faster or less resource intensive to not have to spin up a VM but I've been in .NET land with desktop apps and now various web platforms enough to prefer this workflow. For someone like me, this would be for personal usage versus job related activities but I do see the benefit of having the choice. I just hope I'm strong enough to resist the temptation because my personal win10 laptop is a graveyard of rails installer and a few other various barely-supported toys.

you don't pay for RAM that the VM doesn't use and don't have to deal with madness that is sharing files over sftp/smb/nfs/shared folders/etc.

A smart VM will have ballooning to not throw away unused VM memory.

Because it's a fraction of the resource cost, and shares resources better with the host system as well?

So VS can do C/C++ compilation now. I wonder if they will extend VS to work with other higher-level languages like Ruby and Python (et. al.) ?

It would be nice to work from Windows but build for Linux that way, for other languages too.

Uh.... VS has always been able to do C/C++ compilation. Like... for decades now? Just not with the standard Linux toolchain, but you've always been able to build C/C++ projects on Windows.

Not only that, but Visual Studio is based off Visual C++ in the first place.

Thanks for the downvote guys. I wasn't born under a rock.

The article was talking about Windows Subsystem for Linux, and my comment was that VS can do C/C++ for Linux. I thought that was implied by the context.

Anyways, I know VS has done C/C++ for forever. :)

Yes, in Insider build 14965, we added NETLINK_ROUTE's RTM_GETLINK and RTM_GETADDR support which enabled ifconfig and network connection enumeration support : https://msdn.microsoft.com/commandline/wsl/release_notes#bui...

VS not only could build C and C++ since I can remember, but was a pioneer in the recent C++ revival. Btw VS 2015 installer offers Python tooling install if I remember correctly. See also: https://github.com/Microsoft/PTVS

In case the context didn't make it obvious... I know that VS is based on, and can do compilation for C/C++. I was saying basically, "Oh cool. You can do VS compilation of C/C++ for Linux now. Do you plan in introducing it for other higher-level languages too? (Ruby, Python, et. al.)"

> - vt sequences fixed (so stuff like colored output, midnight commander, etc work and the terminal doesn't screw up)

Does this mean tmux will work?

I'll just leave this here: https://blogs.msdn.microsoft.com/commandline/2016/06/08/tmux... :)

I'll just leave this here: https://github.com/Microsoft/BashOnWindows/issues/406

The OP asked if TMux worked on WSL, which it does.

Now, there are many, MANY, improvements required of Windows' Console which is currently receiving its biggest overhaul in > 30 years! Bear with us while we give the Console some much needed TLC and start to re-shape it into a clean Console infrastructure that supports modern Console demands.

I currently have zero issues running tmux and bunch of other software in mintty/wsltty

https://github.com/mintty/wsltty

tmux should have already worked quite well in Anniversary Update (14393). There are some specific feature enhancements, such as 256/24bit color support (although tmux doesn't support 24bit color by default) and mouse mode support that should make tmux much more usable.