Run Bash on Ubuntu on Windows | Hacker News Reader

Run Bash on Ubuntu on Windows

blogs.windows.com

56 pointsjessaustin44 comments

https://hn.algolia.com/?query=bash%20windows&sort=byDate&dat...

"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"

Challenge accepted!

Here are some details of the challenge that you have set yourself: https://news.ycombinator.com/item?id=11416376

>This is not a server platform upon which you will host websites, run server infrastructure, etc

Yet they demo'd a website being hosted via the Linux sub-system -_- thanks microsoft!

well you've gotta be able to test your applications locally ;)

No, they demonstrated developing and testing a Ruby application on Windows via the Linux sub-system, then deploying it to Azure (using ssh, mina and git).

Important distinction - they're building support for developing Linux-based web applications into Windows, not hosting websites.

I wonder if PG will update his "Microsoft is dead" prediction. Nadella seems to have resurrected Microsoft. I can't imagine them doing this under Ballmer or Gates.

He might modify it to be "Windows is dead." Microsoft has moved on the focusing on the cloud (unsurprising with Nadella). Windows is only ~10% of total revenue.

This story has deeper analysis: http://www.computerworld.com/article/3041378/microsoft-windo...

This is a nice move, but if you think this changes the "Microsoft is dead" statement (not prediction) then you don't appreciate what Microsoft was as compared to what Microsoft is today.

In the 1990s, Microsoft was in many tech markets the default winner, with such powerful monopoly influence that large classes of startup idea would not even make sense to consider because Microsoft was just so well set up to kill any threats to their dominance. And quite willing to do so.

This is a level of dominance and ferocity that has not been attained by other tech companies since. Companies like Apple, Google, and Facebook have pretty strong dominance powered by their lead in product quality, engineering talent, and brand/network effects, but it doesn't strike fear into people the way Microsoft once did. Plus, there is some balance of power among them.

Microsoft now is a participant in this power dynamic. They play in the normal way, by trying to make good products and attract developers and users to their platform. In the 1990s, this would have seemed a pathetic weakness. That Microsoft is still dead.

I remember. So, M$FT is dead, long live MSFT?

Past the headline, PG never claimed MSFT would actually die (or even cease to make lots of money). http://www.paulgraham.com/microsoft.html

"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."

To me, that means that it's less useful than Cygwin currently.

In that vein, see https://news.ycombinator.com/item?id=11416392 .

Posix on Windows! Yay! Together with the open sourcing of DotNet (that now enjoys an MIT license), this new Microsoft stance is looking more and more compelling. Comparing MS policies that to the rather hostile licensing/litigation policies of Java/Oracle makes me reevaluate.

For those that haven't seen it, this isn't the first time (or even the second time) that Microsoft has released a POSIX layer for Windows:

https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem

https://en.wikipedia.org/wiki/Windows_Services_for_UNIX

And they all suck (but are better than nothing). I really wish I could get the windows socket() function to return an integer.

Sure wish they'd discuss a release date...

My theory is that it got announced / leaked way too early. Although, the driver files have been in the Preview builds for a while now.

It seems weird to me that conhost.exe handles how console commands are displayed. I've read where some 3rd party attempts to improve the terminal experience on Windows have done so by essentially scraping what conhost outputs and then using the data to display output themselves.

Am I wrong about this? I have never worked on terminals so I very well could be, but my expectation would be that terminals call into shell APIs which return a result that the terminal can then display however it wishes. If so, then I think the next natural step would be for Windows to decouple conhost's responsibilities.

This isn't as necessary as it used to be: conhost.exe got a major overhaul in Windows 10 and it sucks a lot less now. There's wrapped selection, copy/paste, and transparency (if you're into that). There's plenty more to go but overall the experience is no longer pull-your-hair-out agony, and Microsoft did say (without providing any specifics) that more improvements were on the way and that they are still soliciting feedback and feature suggestions. You could propose changing the way commands are displayed if you wanted.

Those improvements are nice, but ultimately 3rd party terminals should be able to handle display completely by themselves. Is this now possible?

From what I understand, it used to run at way too low a level in the kernel for some reason, so third parties couldn't touch it. This was fixed in Win10 so alternative shells are now possible.

I wonder if this means that Windows will be finally able to use ext3/4 filesystems out-of-box, read and write.

Or Microsoft won't dare to hurt their FAT-LFN & exFAT cash cows and make that "uh-oh developers only" feature? ;)

It's a subsystem for running Linux binaries, unaltered, on top of the Windows NT kernel. There has been no mention of additional Windows NT filesystem drivers, anywhere.

After 30 years using windows this is very good news.

Right now on Windows I use Git Shell which works great but is based on mintty. Will be nice to be something close to native.

Is this in Insider Preview Build 14295 or is there an estimate on when the next preview will be out?

It is not in the current Preview Build; they have said it's coming soon but did not give specifics. Preview builds are pretty fast-paced now (about once a week) so I suspect it won't be long.

No, they said very specifically - in the next preview build, which is in two weeks.

I must've missed that bit. Thanks!

Anyone have the download link? I can't seem to find it.

Does this make msys(git) defunct?

Hasn't msys been half dead for years now? I still use it, but it has felt like it is on its last legs for a long time now.

MSYS2 is very up-to-date. https://msys2.github.io

It uses pacman from Arch Linux as its package manager and it contains many libs in addition to just the compilers (and the unixy tools)

Unlikely msys can handle the DOS/POSIX EOL conversion. Which is something I totally take for granted and is gonna be really annoying to deal with in Windows once BASH support is added.

No. You can run native windows stuff from msys.

Where does it say this can't? I understood the opposite:

...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!"

edit:

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.

So, which is it?

I think it won't be able to run windows program, at least at first, and the reason is probably mainly technical: detecting fork/exec pairs of calls where it should be possible to spawn a PE is non-trivial, especially since you mainly aim at standard Linux syscall compat with unmodified pre-existing GNU/Ubuntu userspace (and Linux does not even uses fork() but clone() as a syscall -- which makes the issue even more difficult to handle).

Now as for what it could be useful for, I guess a lot of people will reclaim a solution to be able to run windows program from that environment, because one of the scenario is build-systems and leaving that to a separated environment would be too bad. At least I will. In the meantime, maybe we will be able to cope with ssh.

Now back to technical stuff, I think the best way to allow execution of windows program from that environment would be a small custom program that uses a special syscall and to spawn a windows process. The end result would not be transparent (you would have to launch let's say "windows cl" instead of "cl" from the Linux env, but this is an extremely small price to pay, since: build-system already often can prepend things to command lines, for example to use ccache, we can actually implement this solution without even needing syscall support but instead TCP/IP (and maybe ssh) and switch to an accelerated para-syscallized solution when it is available -- but then the classical problem of inheriting the environment will reappear (env var to translate with heuristics, etc...)

So maybe MS thought about all that and decided they will "never" do it (until they change their mind in 10 years), and we actually should just stick to MSYS for that kind of stuff? Would be a little sad, but it's not like we are without an existing working solution.

MinGW with native bash would be really cool. That way, I would have the same, and native, build environment on Linux, OSX, and Windows.

Well, MSYS/MSYS2 lets do that today. It would just be more elegant to use native unported Linux binaries from an existing repository (which probably has more tools available too), but even with the low level syscall thing being solved, the other stuff MSYS fixes will reappear (mainly problems about path and environment translation, which is crucially important in build-sys). So we can guess it is at least not for the first version...

Edit: reading your comment again, maybe you will be happy with building your windows exe with a MinGW cross compiler fully running under the Linux subsystem under Windows. That covers some needs, but not all. For example I really need to be able to e.g. launch cl from there with standard Makefiles and GNU Make.

Ah yes, I have yet to venture into the magical realm of cross compiling!

See https://news.ycombinator.com/item?id=11417545 for another aspect of this.

There are probably still enough companies out there which are using Windows 7 as their standard installation. And as long as that's the case msys(git) would still be needed.

Reply on news.ycombinator.com