Hacker News new | ask | show | jobs
by 0xFFC 3535 days ago
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.

4 comments

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
> "Windows ridiculous conemu. I am not going use a console which I can't resize without any problem."

Sorry I don't follow. What resizing problems are you having with ConEmu? Works fine when I've tried it. We are talking about the same ConEmu, right?

http://conemu.github.io/en/

http://conemu.github.io/en/ResizeAndMove.html

The way they phrased it suggests they were referring to the default Windows NT terminal emulator, rather than Conemu.
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.
Cmd.exe is just the shell. The console window is handled by conhost, as are any terminal emulation things.
So sorry about late answer. I meant Windows default console emulator. I forgot what they call it exactly.
Ah, fair enough.
> Parameters are passed to the Windows binary unmodified. As an example, the following commands will open C:\temp\foo.txt in notepad.exe:

This might rain on your parade a bit. Each island still has to know about the file sytem of the other island.

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.

I will, they've been clear about it being a work in progress.

There are a lot of other people saying how amazing it is though, when functionality wise it's only just coming up to par with cygwin.

Edit - functionality wise as a usable bash shell, it's an acceptable linux virtual machine already.

It is not a virtual machine and doesn't involve Linux in any way. It is an implementation of the Linux syscalls for the Windows kernel.
Why does this trigger so many people?
Why is “trigger” used jokingly now? Unless you think the people responding have PTSD or a similar condition.
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.
Actually,what does an emacs server running in wsl get you rather than just running the standard win32 build?
Emacs on win32 dosnt support daemon mode.
You should upgrade. Emacs 25.1 supports daemon mode in Windows.
So cool. I should really really think you. Wasn't aware of that.