Yes, that's really the missing piece and sounds great. Before that it really felt isolated, like working in a VM. My use-case was to have a full featured bash for invoking some build scripts built still to be able to utilize some windows executables (most imporantly currently docker for windows) in it. Seems like this should do it.
Yes, I also use git bash / msys currently and I'm pretty happy with it. But there were a few cases were it caused problems, e.g. the automatic translation of file names caused some headaches for me (in most cases you want it, but e.g. in docker statements you don't want it). Wanted to try whether WSL can even improve that. The old version was unfortunately too limited, but this update sounds very promising and I will test it again.
No more so than any of the shells that's already available on Windows (batch scripts, WSH, Powershell). If one was to exploit scripting on Windows, it would make more sense to target the existing shells rather than Bash as they're more widespread on Windows.
Plus Bash on Windows isn't a new thing: we already have Cygwin, MinGW and I believe there was also some native Windows PE ports too. This is just a better implementation than the aforementioned three.
Wow, this is really impressive. Last time I worked with bash on Windows it felt like isolated island. But with this. I think it is a viable option right now. The only down side to it is slow file system operations. Compiling a single toy kernel (xv6) would take much longer than Linux.
This is amazing, now I can have emacs server in Linux running through bash with windows service manager.
This is fucking awesome. I hope they improve thing further and further.
The only and biggest problem : Windows ridiculous conemu. I am not going use a console which I can't resize without any problem. For the sake of God they don't have unlimited buffer option and hide scrollbar (permanently) or resize window without messing up text.
I've actually been running an instance of VcXsrv and then running something similar to `bash -c "DISPLAY=:0.0 terminator` to run that under the X session. Way better than the CMD emulator
I would agree with you, but that'd be the first time I've ever heard that called ConEmu. It's much more likely to be called the Windows command shell, Windows command prompt or cmd. As you're clearly already aware, ConEmu is a specific product that provides an enhanced command line experience on Windows.
FWIW, `cmd.exe` is both, the shell and the console. It is not a terminal (not designed to be operated remotely) nor is it emulating a terminal of any kind.
As for the parent poster, they must be abusing the term `ConEmu`, a completely separate console program that can run win32 programs (including `cmd.exe`).
If it helps futher square some of the linguistics digressions the parts of cmd.exe that are the console emulator are typically referred to as the ConHost. The ConHost's console emulation is indeed not quite as great a lot of people would like, which is why many Windows users use a different console emulator named ConEmu. Obviously abbreviating the ability of ConHost's console emulation to conemu rather than spell out "console emulation" causes confusion with the ConEmu tool for Windows.
Cutting them some slack I think is not bad idea. They are literally integrating two big operating system together. Do you see what I am saying?
As we all know Microsoft messed up with mobile and web, but when it comes to software development they are ruler without even competition. Windows kernel is wonderful peace of software, and with this wsl they are literally showing industry how is software developed.
> Because self diagnosed PTSD sufferers on Tumblr made a mockery of it.
Why would them being self-diagnosed matter? Why would you react to it having been “made a mockery of” by reinforcing this supposed mockery? It only makes it worse for people who have to deal with it.
Because the self diagnosis is largely made up by people who don't understand what PTSD even is. It's like someone declaring they have cancer without going to a doctor.
> Why would you react to it having been “made a mockery of” by reinforcing this supposed mockery?
Because it's become part of the lexicon now. I don't think there's any going back. My usage was the "new" usage, no relation to PTSD was intended.
I have to agree... I'm still using the bash that comes with git for windows. It actually works (mostly) as one would expect it to work.
Also, not being able to edit the WSL filesystem from inside a windows editor is a huge loss in terms of usage. It's worse than using Samba/CIFS to share a directory and edit across to a full VM. I happen to like my gui editor, but prefer to run in Linux.
If you had to you can touch things in the WSL VolFS by browsing the appropriate %AppData% subfolder. I'm presuming Microsoft isn't encouraging that right now with this Interop tooling for several reasons.
At a guess one of them might be that apparently the Unix things like permissions and Unix-style metadata are stored in NTFS alternate streams (~"resource forks") that they may be worried some Windows programs might not handle quite right (ie, accidentally mangle/remove/destroy).
It actually doesn't work right, and MS just closed the issue. I'd be fine with cifs automounts in the linux subsystem for windows file directories... I mean it may take a little work, but in the end, I want to edit files with a windows gui editor, and run them via the LSW applications. Until I can do that, it's an also ran on the desktop... and until it can be used for docker with linux containers on the server, it doesn't do much use there either.
Why can't you keep the shared files that you want to GUI edit somewhere under /mnt/?/* in a normal NTFS folder? That works fine already today.
I'm using Bash on Ubuntu on Windows for Jekyll (because installing and keeping up to date Ruby on Windows is a terrible experience and this is a much nicer alternative). My files are in D:\Repos\..., I'll have VSCode open and Jekyll running in Bash in the equivalent /mnt/d/Repos/...
Now they just need a better terminal emulator. Windows 10 made some minor but much needed adjustment, but I still end up using Cmdr (a nicely preconfigured ConEmu), and it's decent enough, but it pales over a nicely configured iTerm2 or what most popular Linux distros come with out of the box.
We're not on Windows 10 yet at my workplace, and I don't use Windows at home, so I've only been following loosely in a "this will be nice once I'm finally able to use it" way. But this bit took me by surprise:
> 1 Use the same working directory as the CMD or PowerShell prompt
> 2 Are run under as the WSL default user
> 3 Have the same Windows administrative rights as the calling process and terminal
1 and 3 are not surprising. But 2? There's a WSL default user? Windows users aren't automatically mapped to unique Linux users? That seems problematic in theory. How does it work out in practice?
It seems to work pretty well in practice. The entire Ubuntu "system" is essentially installed into a Windows User's home space, which means that all of the Linux users are unique to a Windows user. This is useful in that you can install things that need Linux accounts for services (like say postgresql that uses a postgres user as a service account) and interact with it with sudo -u just as you would on an ordinary Ubuntu machine. With the interesting bit that the postgres user under my Windows user login would be different from the one under a different Windows user on the same machine, but that also has some advantages.
If there's ever been a great opportunity to open source something in the Windows client, it's WSL. A number of popular User Voice feature requests were closed recently as not in scope, which is reasonable on the part of the WSL team but shows that the demand for Linux-on-Windows is much greater than the team's current objectives. If the project was open source and the team accepted patches who knows where this thing could go. People want to run X, they want device emulation, they want to run all kinds of apps that aren't necessarily dev tools.
