From reading that blog, and also: https://github.com/Microsoft/BashOnWindows/issues/111#issuec... it sounds as if the Windows console (separate from bash, openssh, powershell etc) is being entirely refactored for creators update. So those fixes should also help powershell, ConEmu and a bunch of other common windows command line stuff.
I've been running windows (using WSL for most of my development) for a few months and overall I'm very happy with it. Every non-GUI linux program I want to run works just fine on WSL, with the sole exception of (beta software) Urbit.
I do miss Xmonad-like window management, but windows does have shortcut keys that do a good enough job. Emacs works perfectly well. And Anaconda (https://www.continuum.io/downloads ) is actually a good native windows distribution of Python and Julia.
Cortana + voice recognition is actually pretty cool, I'm looking forward to hacking on it when MS releases the dev kit.
So far, windows seems to be an acceptable Linux. I will probably stick with it for a while, assuming I don't run into any crazy new blockers.
Emacs has one flaw for me under WSL: the janky Windows console doesn't pass C-SPC. Meaning I have to bind set-mark-command to something else (like M-SPC), or download and use wsltty (fork of mintty).
But other than that Emacs is fine, and a lot of Linux stuff (Node, mongo, etc.) works great.
I'm pretty happy with it too. For the things that are implemented, it works better than MacOS did as a casual Unix for me. Mostly because I prefer the Ubuntu tools. I'm still using a genuine Linux box for real work though.
The big feature I'm missing is network file systems.
The biggest problem I have with the WSL is that it is intrinsically tied to stable Windows releases; there is no way to get incremental updates for Bash on Windows unless you subscribe to the Windows Insider program, which is a way of running prerelease versions of Windows.
So in order to get Linux features like inotify working you have to sacrifice the stability of your operating system.
This looks like it'll be true till the end of time. Does your dev work depend on bug fixes or certain syscall implementations? Well, either run an OS that may or may not work at any given time or wait several months for the next release.
A couple weeks back I tried to give WSL a try but everything was broken. Inotify prevents hot reloading, which really makes my life just dandy, so I tried to transition to the insider program in order to get my fix. To my chagrin, this caused Node to up and break on me. Like, full stop doesn't work anymore.
I ended up going back to Linux. I really hope that developing on Windows becomes something other than 'awful' - for me at least - but I don't think it's quite there yet.
@OhSoHumble: We totally hear you. We'd love to ship WSL builds uncoupled from the rest of the OS, but at the moment, we're developing WSL at a breakneck pace alongside several other critical kernel feature changes which all have to ship in lock-step.
A good example of this is the work we've been doing with the networking team to add additional network socket mode support to the NT kernel's networking stack so that we can create the correct socket semantics that Linux apps expect. We're also working with the NTFS team, process & scheduling team, management infrastructure, etc.
I think you are being too harsh -- this is an in-development feature. Once it gets stable things should "just work", and you'll get an update in a few months, like most pieces of software. At the moment you wouldn't want to rely on the beta version for anything important -- some betas are fairly broken (as you would expect with betas).
It is unfortunate that Microsoft couldn't figure out how to write this in a less kernel-attached way, but this is adding some powerful new functionality at many levels of the kernel, that will hopefully provide long-term benefits.
that's a 10yr old bash and there's barely any shell magic that you can do on Linux that won't work on macOS. And since by far most devs use macOS, most binaries support at least the macOS version of bash. All in all, no need to worry :p
Not since Windows 2000 have I been so interested in an upgrade to a new Windows release. Only at work do I have to suffer through Windows, but this would make things much nicer there.
I hope/pray that readline and/or editline work correctly on bash et al?
Do Windows CI services like Appveyor support WSL? If so I would hope that deploying to windows for lots of high level software is relatively painless.
Head scratcher from the video:
> What if I want to open this file in notepad?
> ... <demonstrates opening notepad from bash>
> audience applauds
Ugh, the only thing worth applause here would be if instead he had said "and we finally taught notepad how to work with different line-endings" or "and we finally deleted notepad". The demo clearly shows the shebang line mashed in with the rest of the file contents. "This was a very popular ask" -- from whom‽ To present things as a dichotomy between vim and notepad is not honest.
EDIT: comments below have clarified: the feature refers to launching Windows processes from linux ones, not notepad specifically.
Yea, fedora user at home, stuck on Windows 7 at work. I've actually started to pick up some Powershell for some light scripting. Have had a request in to the Vogons in IT to install python for windows for about 3 weeks now and I'm still waiting...
> Not since Windows 2000 have I been so interested in an upgrade to a new Windows release.
Well, yeah, Windows has been in the dollar milking phase for quite some time now (at least a decade).
It's no longer about delighting the user (yes, even Microsoft used to do that!). Or even just keeping them happy. It's just about keeping them not unhappy enough to switch to the alternatives.
I Still wish they did the opposite. I want to seamlessly run an occasional windows app in linux, and I would pay for it. There is literally zero chance of me switching back to windows for day to day usage.
Edit:
idobai, I can't reply because your account is banned, but last I tried Wine and Crossover do not work for the apps I am trying to use.
Edit 2:
cyloneyes, you're banned too. But "They" would be Microsoft. They are the only ones who could really do it.
Just a note to anyone looking to go down this road: IO performance is still pretty awful last I checked. If your workflow is IO intensive (non trivial Rails app, let's say), proceed w/ caution.
(Addendum) I did a Fast Ring update on a separate machine and did not see substantial performance improvements, but the comparison is not valid between the machine linked and the machine I tested on, so I'd be hesitant to say that the performance hasn't improved at all, just that IO performance is definitely a weak point to WSL.
Is this why Visual Studio is scp'ing source files around, instead of just copying the files to that /mnt/d directory and invoking the compiler there? That seemed like a big hack to me and it wasn't exactly clear why they were doing it that way (near the end, last five minutes).
With Visual Studio Code, Microsoft is making Windows 10 really appealing to developers. I personally won't jump any time soon, I am really satisfied with my work environment on macOS (and Linux inside VM) (unless I got locked down into Microsoft stack for work, in that case I will gladly switch, but it's not like I will have any other option). But anyway, I recognize and appreciate the change at Microsoft's direction of thinking, it's awesome! I wouldn't believe if somebody told me this 10 years ago...
those are some cool changes. For those who can't/don'w want to watch the video:
- 24 bit color support added.
- lots of work to support more programs
- launch windows programs from bash (notepad.exe for instance)
- file change notification support (to allow for automatically rebuilding a website on file change for instance)
- can build a C++ project in Visual Studio and deploy it to your local WSL env, so you can run it directly from the local bash. (Visual Studio generates real linux binaries : ELF 64 bit lsb executable)
- Remote GDB Debugger: Can use visual studio debug engine to debug linux executables (It looks like this was possible before for remote machines [1], but now it can be done locally on a program running in WSL.)
Dumb question: Why did they name this "Subsystem for Linux"? (Old name was Interix, subsystem for UNIX-based applications, or "SUA".) Does marketing/users believe there is a distinction between Linux as a kernel and GNU as a source for a userland? Irrelevant? Curious what others think.
How is the file system performance going with this? The latest release version runs Rails worse than shared folders on VMWare which is slow in bad way. Running MySQL on top of it might "work" but is it fast?
With something called Cygnal, you can make native Windows applications, while taking avantage of all the POSIX interfaces in Cygwin. No special subsystem required, just some DLL's.
Newb question, does this "Winbash" run Linux/posix/unixy binaries that wouldn't otherwise run or does it assume the actual Windows dists/builds for (Elixir / Go / PostgreSQL / MySQL / GHC / etcpp)?
I think "bash on Windows" is not a valid way of describing what it is.
Cygwin, which allows you to run bash among many things, has been available for TWENTY TWO YEARS now. However it required such software to be ported and recompiled specifically for its use with Cygwin.
The difference this time is being able to run unmodified Linux software on Windows, through an application binary interface called Windows Subsystem for Linux or WSL.
"Bash on Windows" is the least tech-savvy way to describe what is going on.
> Bash on Windows or Bash/WSL got the most votes in early polling while we were choosing a descriptive name for this unusual feature, especially compared to WSRPGLB (Windows Subsystem for Running POSIX, GNU, Linux Binaries) which felt a little cumbersome
Can anyone please tell if Windows SubSystem for Linux coexists well with Cygwin64 and/or msys? I have Cygwin64 installed. I don't use it a lot but it helps to run some deployment bash scripts which otherwise won't run on Windows. So it will be good to know if Windows SubSystem for Linux messes up with it or not.
Both run fine next to each other. The only conflict I can think of is if you don't call "bash" via a complete path, but rather rely on PATH environment variable.
Btw. any reason you are not running those bash scripts in WSL now?
Along those lines, a great trick for Go on Windows is to set your $GOPATH outside of the WSL filesystem, so you're developing in, e.g. /mnt/c/. This gives you full access in both Windows and Linux to your Go project, so if you need to open a file in Photoshop, etc. it's painless.
Any news about 256-color support? I understand the desire for the extreme backwards compatibility, but it requires some manual magic done to display things properly in fish (which, thankfully, works really well with Bash on Windows after the aforementioned magic), and even then it will only support 16 colors.
Yes, we support every color sequence there is now, for full 256color/24bit color support.
At this point, I believe the terminal emulation is pretty close to complete, so if you notice any other shortcomings, make sure to take a look at or GH page for issue reporting:
The way I solved the terminal emulator shortcommings is this: Install a gtk-based terminal emulator with gtk/gnome dependencies on you ubuntu subsystem and run it with `DISPLAY=localhost:0.0` environment variable. This works if you run XServer Client on your Windows side. I use XcSrv and pantheon-terminal.
It might work in ConEmu. As for the native Windows console, I wouldn't hold my breath, considering that that'd be rather incompatible with the current framebuffer and would probably require a lot of new Windows APIs.
When I was playing around with WSL a few months ago, I came across this emphatic caution from the devs to not modify any files in the Linux subsystem using Windows applications (aka anything with a GUI)[1]. Apparently it destroys file metadata and breaks things.
I know it's not that hard to keep your stuff in /mnt/c or wherever, but I wonder if there is any plan (or if it's even possible) to eliminate this last bit of incompatibility.
Is it possible to run a GUI version of the Linux version of VSCode on WSL?
I've been sing the Linux subsystem in my new Windows install for the last couple weeks, after buying my first new PC and first Windows machine in ten years. It's actually very impressive, and I like it.
My PC has a super loud fan system that requires software support to control to get it quiet. Under my Linux install this was turning into a configuration nightmare, trying to find the right incantations -- under Windows it is working nicely. As are the video drivers.
So I am doing my development in the Windows version of CLion, but doing the actual compiles and git usage etc. in the Linux subsystem. It's working really nicely. And for the few GUI I need, apps I run Xming and set my DISPLAY and it works perfectly.
[+] [-] nailer|9 years ago|reply
- vt sequences fixed (so stuff like colored output, midnight commander, etc work and the terminal doesn't screw up)
- Elixir and Go work
- Also Postgres and MySQL
- You can launch Windows apps from bash.
- inotify works
- Visual Studio can compile with GNU/Linux C/C++ tools, gdb, linker etc
There's some recent fast ring info on: https://blogs.msdn.microsoft.com/commandline/2017/01/09/bash...
From reading that blog, and also: https://github.com/Microsoft/BashOnWindows/issues/111#issuec... it sounds as if the Windows console (separate from bash, openssh, powershell etc) is being entirely refactored for creators update. So those fixes should also help powershell, ConEmu and a bunch of other common windows command line stuff.
[+] [-] yummyfajitas|9 years ago|reply
I do miss Xmonad-like window management, but windows does have shortcut keys that do a good enough job. Emacs works perfectly well. And Anaconda (https://www.continuum.io/downloads ) is actually a good native windows distribution of Python and Julia.
Cortana + voice recognition is actually pretty cool, I'm looking forward to hacking on it when MS releases the dev kit.
So far, windows seems to be an acceptable Linux. I will probably stick with it for a while, assuming I don't run into any crazy new blockers.
(I've been on Linux exclusively since 2001 except for a brief attempt to use OS X around 2009. That experiment was less than successful: https://news.ycombinator.com/item?id=1786930#1787411 )
[+] [-] bitwize|9 years ago|reply
But other than that Emacs is fine, and a lot of Linux stuff (Node, mongo, etc.) works great.
Who cares if Urbit doesn't work? :)
[+] [-] stinos|9 years ago|reply
Most gui programs seem to work ok as well, though you do need an X-server running on Windows (e.g. the one in MobaXTerm does the job)
[+] [-] NelsonMinar|9 years ago|reply
The big feature I'm missing is network file systems.
[+] [-] avtar|9 years ago|reply
Do you use spacemacs by any chance? I tried emacs with WSL when the Anniversary Update was released and ran into this issue:
https://github.com/Microsoft/BashOnWindows/issues/639
I'll try it again when Creators Update is available and hope for the best.
Edit: NM, just saw below, after I posted this message that you're using the Windows emacs build.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] OhSoHumble|9 years ago|reply
So in order to get Linux features like inotify working you have to sacrifice the stability of your operating system.
This looks like it'll be true till the end of time. Does your dev work depend on bug fixes or certain syscall implementations? Well, either run an OS that may or may not work at any given time or wait several months for the next release.
A couple weeks back I tried to give WSL a try but everything was broken. Inotify prevents hot reloading, which really makes my life just dandy, so I tried to transition to the insider program in order to get my fix. To my chagrin, this caused Node to up and break on me. Like, full stop doesn't work anymore.
I ended up going back to Linux. I really hope that developing on Windows becomes something other than 'awful' - for me at least - but I don't think it's quite there yet.
[+] [-] bitcrazed|9 years ago|reply
A good example of this is the work we've been doing with the networking team to add additional network socket mode support to the NT kernel's networking stack so that we can create the correct socket semantics that Linux apps expect. We're also working with the NTFS team, process & scheduling team, management infrastructure, etc.
[+] [-] CJefferson|9 years ago|reply
It is unfortunate that Microsoft couldn't figure out how to write this in a less kernel-attached way, but this is adding some powerful new functionality at many levels of the kernel, that will hopefully provide long-term benefits.
[+] [-] bitcrazed|9 years ago|reply
"A couple weeks back I tried to give WSL a try but everything was broken"
Did you run an Insider build? 14986 completed a batch of inotify related syscall improvements since we first added inotify support in 14328 (Details here: https://msdn.microsoft.com/commandline/wsl/release_notes)
[+] [-] tornadoboy55|9 years ago|reply
`GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16) Copyright (C) 2007 Free Software Foundation, Inc.`
that's a 10yr old bash and there's barely any shell magic that you can do on Linux that won't work on macOS. And since by far most devs use macOS, most binaries support at least the macOS version of bash. All in all, no need to worry :p
[+] [-] oblio|9 years ago|reply
On top of it, the Ubuntu userland should be freely upgradable - I think.
[+] [-] kirkdouglas|9 years ago|reply
[+] [-] wyldfire|9 years ago|reply
I hope/pray that readline and/or editline work correctly on bash et al?
Do Windows CI services like Appveyor support WSL? If so I would hope that deploying to windows for lots of high level software is relatively painless.
Head scratcher from the video:
> What if I want to open this file in notepad?
> ... <demonstrates opening notepad from bash>
> audience applauds
Ugh, the only thing worth applause here would be if instead he had said "and we finally taught notepad how to work with different line-endings" or "and we finally deleted notepad". The demo clearly shows the shebang line mashed in with the rest of the file contents. "This was a very popular ask" -- from whom‽ To present things as a dichotomy between vim and notepad is not honest.
EDIT: comments below have clarified: the feature refers to launching Windows processes from linux ones, not notepad specifically.
[+] [-] ohstopitu|9 years ago|reply
For a while, it was impossible for windows programs and WSL content to mix (and if you could somwehow do it, it was highly discouraged).
But that's no longer the case. Notepad is just an example to prove this point.
[+] [-] oblio|9 years ago|reply
It truly is a Notepad. It launches quickly and has a non-nonsense interface.
It's not meant to be a programmer's editor. It never was, it never will be.
[+] [-] sbarre|9 years ago|reply
This had nothing specifically to do with Notepad, I would bet they just used it as a simple example.
[+] [-] struppi|9 years ago|reply
Basically this: http://stackoverflow.com/questions/38920710/how-can-a-run-wi...
[+] [-] nailer|9 years ago|reply
Demoer specifically comments that it's broken (obvously CR/LF differences) and they're fixing it.
Also VS Code for Windows might have been a better example than Notepad but you get how this could be useful.
[+] [-] jcadam|9 years ago|reply
[+] [-] matthewaveryusa|9 years ago|reply
I think visual studio code is what you're looking for.
[+] [-] baq|9 years ago|reply
i'll admit i'm super duper happy about this, can't wait for $WORK OS upgrade.
[+] [-] johansch|9 years ago|reply
Well, yeah, Windows has been in the dollar milking phase for quite some time now (at least a decade).
It's no longer about delighting the user (yes, even Microsoft used to do that!). Or even just keeping them happy. It's just about keeping them not unhappy enough to switch to the alternatives.
[+] [-] dec0dedab0de|9 years ago|reply
Edit:
idobai, I can't reply because your account is banned, but last I tried Wine and Crossover do not work for the apps I am trying to use.
Edit 2: cyloneyes, you're banned too. But "They" would be Microsoft. They are the only ones who could really do it.
[+] [-] netshade|9 years ago|reply
https://www.reddit.com/r/bashonubuntuonwindows/comments/5ece... - My last check.
[+] [-] netshade|9 years ago|reply
[+] [-] castratikron|9 years ago|reply
[+] [-] Philipp__|9 years ago|reply
[+] [-] vmarsy|9 years ago|reply
- 24 bit color support added.
- lots of work to support more programs
- launch windows programs from bash (notepad.exe for instance)
- file change notification support (to allow for automatically rebuilding a website on file change for instance)
- can build a C++ project in Visual Studio and deploy it to your local WSL env, so you can run it directly from the local bash. (Visual Studio generates real linux binaries : ELF 64 bit lsb executable)
- Remote GDB Debugger: Can use visual studio debug engine to debug linux executables (It looks like this was possible before for remote machines [1], but now it can be done locally on a program running in WSL.)
[1] https://blogs.msdn.microsoft.com/vcblog/2015/11/18/announcin...
[+] [-] notheguyouthink|9 years ago|reply
Who knows, in 3 years i might be able to ditch OSX for Windows, because some of the Surface devices actually look decent (no idea how true it is tho).
[+] [-] gwu78|9 years ago|reply
[+] [-] inestyne|9 years ago|reply
[+] [-] kazinator|9 years ago|reply
http://www.kylheku.com/cygnal/
[+] [-] dualogy|9 years ago|reply
[+] [-] partycoder|9 years ago|reply
Cygwin, which allows you to run bash among many things, has been available for TWENTY TWO YEARS now. However it required such software to be ported and recompiled specifically for its use with Cygwin.
The difference this time is being able to run unmodified Linux software on Windows, through an application binary interface called Windows Subsystem for Linux or WSL.
"Bash on Windows" is the least tech-savvy way to describe what is going on.
[+] [-] 1wd|9 years ago|reply
https://blogs.msdn.microsoft.com/vcblog/2017/02/08/targeting...
[+] [-] pritambarhate|9 years ago|reply
[+] [-] chrisper|9 years ago|reply
Btw. any reason you are not running those bash scripts in WSL now?
[+] [-] emh68|9 years ago|reply
[+] [-] chrisper|9 years ago|reply
[+] [-] hellcow|9 years ago|reply
[+] [-] kaio|9 years ago|reply
[+] [-] filoleg|9 years ago|reply
[+] [-] zadjii|9 years ago|reply
At this point, I believe the terminal emulation is pretty close to complete, so if you notice any other shortcomings, make sure to take a look at or GH page for issue reporting:
https://github.com/Microsoft/BashOnWindows/issues
[+] [-] imslavko|9 years ago|reply
[+] [-] ygra|9 years ago|reply
[+] [-] CRUDmeariver|9 years ago|reply
I know it's not that hard to keep your stuff in /mnt/c or wherever, but I wonder if there is any plan (or if it's even possible) to eliminate this last bit of incompatibility.
Is it possible to run a GUI version of the Linux version of VSCode on WSL?
1. https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n...
[+] [-] tambourine_man|9 years ago|reply
[+] [-] cmrdporcupine|9 years ago|reply
My PC has a super loud fan system that requires software support to control to get it quiet. Under my Linux install this was turning into a configuration nightmare, trying to find the right incantations -- under Windows it is working nicely. As are the video drivers.
So I am doing my development in the Windows version of CLion, but doing the actual compiles and git usage etc. in the Linux subsystem. It's working really nicely. And for the few GUI I need, apps I run Xming and set my DISPLAY and it works perfectly.