Hacker News Reader

Comment by pjungwir | Hacker News Reader

When I have to work on a Windows machine the first thing I install is git: https://git-scm.com/downloads

It comes with bash and all the standard tools (including ssh IIRC), so I can work on a real command line. Especially as a vi user, I'm right at home.

I find this a lot easier to manage than Cygwin: a lighter install, no packages to select, and smoother integration.

View on HN

These days you go to the Microsoft App store and download Ubuntu. It loads up actual bash and comes with everything you'd expect. (ssh being just one of the things). The terminal emulation is improving (there are still a couple of glitches) but pretty much all of my daily tools work exactly correctly.

Is there any advantages over using Ubuntu itself directly?

The big advantage is that it runs within Windows, so you can use your Windows and Linux tools at the same time. It's also not done as a virtual machine, so the Ubuntu running on Windows can access and manipulate files on your Windows system very easily.

Albeit very slowly. Unless they fixed it recently, writing to a vast amount of files is very slow compared to native Linux. Anyone who has cloned a large repository I'm sure is aware of this.

I felt like file speed sped up quite a bit in the Fall Creators Update, though of course that notion is entirely anecdotal.

Also, the native Windows git is still your best bet for git operations. That's one of the cases where I will have a PowerShell and an Ubuntu bash window side-by-side, working in the same /mnt/d/... | D:\... directory. git operations in PowerShell and Jekyll (or whatever) operations in Ubuntu bash.

Does it make a difference if you run your git operations through cmd from the bash command line? If so, is there a simple way to automatically get the current windows path from pwd? If it's the same speed as native git running in a separate window (I think it should be), it might be worth coming up with some kind of script to do this automatically. Not sure how to get that working with using Linux tools within git, though (editing commit messages, diffing, etc). Also, how does file speed within the Linux environment (/home/username) compare to that outside (/mnt/C/whatever)?

Also, they _really_ chose a poor name for that executable; it should have been wsl.exe or some such, not bash.exe. At least lxss.exe isn't already in use by other software in my path...

I hadn't thought about that (I use PowerShell for most tasks so that is still my "home" shell and it's bash that's the rare one), but I half remembered something to that effect, so I went to the docs:

https://docs.microsoft.com/en-us/windows/wsl/interop

Calling Windows EXEs from bash will automatically retain the current working directory under /mnt/c/*, so it should just work out of the box. Looks like you might be able to get away with just adding native Windows git to your bash path.

Yeah for example I have composer only installed in Windows (EXE) and not within WSL and it works fine within the bash prompt.

We just released a tool to do the right path translation -- wslpath. Unfortunately we haven't added built in usage info yet. Here's a link[1] to usage info in recent Windows Insider flights.

Also, totally fair feedback about the naming. In FCU, we added wsl.exe in addition to bash.exe. It launches into your default shell rather than /bin/bash.

[1] https://github.com/Microsoft/WSL/issues/2715

* I work at Microsoft on WSL

Well not if you aren't using other parts of Windows :-) but if you are constrained to using Windows for other reasons then the advantage is you get all the tools with a much lighter weight system than say running a virtual machine.

There are also some systems where kernel support for the devices is lagging, either because they are proprietary and poorly documented or because they have insufficient market penetration to get someone interested in writing good driver support. For example support for the pen on the Surface Pro 4 line is really horrible (IMHO) on Linux.

So these devices need real kernel drivers? Windows doesn't provide some kind of emulation through its own drivers? I guess that makes sense although it didn't occur to me.

If that's true, will those new drivers also work on a regular non-Windows Linux install? That would be really great news, and pretty ironic, if device manufacturers or even Microsoft itself were suddenly writing more/better drivers for the Linux kernel. :-)

The grandparent is saying that if you run plain Ubuntu directly on a device, Ubuntu (or really, the Linux kernel) might not have drivers that work reasonably well for some hardware on that device, while Windows most certainly does have decent drivers for that hardware.

When you run Ubuntu on top of windows, windows replaces/emulates the Linux kernel - at least the part it needs to run the subset of Ubuntu that windows currently can - this emulation provided to run Ubuntu is done on the interface between the kernel and userspace, it is not done on a device/driver level.

Drivers are OS specific, the drivers in question here are either windows drivers, which works only on windows, or they are linux drivers which work only on linux. (Noone is writing drivers for windows which could also work on linux)

It's not an emulator. The NT kernel really does support the necessary system calls.

Sure, but there's a layer that emulates the linux syscalls. Though perhaps it's more appropriate to call it "translates" instead of emulate.

Its not a layer on top of the NT system call infrastructure. Its brand new NT system calls that do exactly what the equivalent Linux ones do. There is no combination of win32 NT system calls that will get you the behavior of fork().

Aren't the NT system calls also just a personality module above the actual NT kernel? The kernel was originally designed to provide multiple kinds of user spaces so that it could run OS/2 programs alongside Win32 ones.

No. win32 is a personality, the underlying ntdll calls are not part of that.

Of course not! It's quite the opposite. With more and more people ditching 'real' Linux for WSL (which is a 'Linux kernel API layer' for the Windows kernel, there is actually NO Linux kernel involved), support for the relevant hardware is never going to happen in Linux proper.

That you can keep using Windows seamlessly?

I haven't done this yet, thanks for the reminder! I've been curious to try it as I've gone through probably every other bash emulator on Windows and not been overly satisfied.

I would love to hear how it works or doesn't work for you! I have shown it to lots of folks and probably a quarter have some aspect that keeps it from being perfect (generally a terminal issue or the lack of a Microsoft provided X server. For the latter I use xwin32 [1] which works fine but may not be accelerated if your display controller isn't supported.)

[1] https://www.starnet.com/xwin32/

I'm just getting set up yet, but so far so good! I haven't run anything too complex just yet, but it seems really performant and doesn't put a significant load on my system.

Next up is to try running something more taxing, and then look into GPU access from within it.

I'm looking forward to them developing the subsystem further.

I tried this, but I found that my Ubuntu subsystem could not access my wifi connection at all, no matter what I tried. I remember reading Microsoft forums where developers from Microsoft acknowledged they were working through the issue. It still hadn't been resolved the last time I checked.

I'm on a Dell XPS 15 9560 if that matters.

> I'm on a Dell XPS 15 9560 if that matters.

It does as I've had no issues personally on as self-built desktop, an ASUS laptop, a MacBook running Bootcamp, and now a Surface Laptop.

For me, this is a huge thing.

When I bought my first Mac, back in the days of MacOS 10.2, I did so because of the BSD system underneath. Having a Unix system, whether its GNU or BSD, gives me access to tools that I'm familiar with and sometimes prefer to their GUI counterparts (e.g., scp/sftp vs FileZilla).

Now that Windows has this, switching back is something that I'm giving serious consideration to.

"Now that Windows has this, switching back is something that I'm giving serious consideration to."

It's not clear to me that Windows has this ...

I, like you, adopted the MacOS ecosystem because it was UNIX underneath ... but there's a big difference between underneath and alongside.

Although it is not commonly done, you can control and interact with your OSX system with UNIX commands ... there's one single filesystem namespace and you can interact with it from the command prompt as well as kill GUI apps or set preferences or ifconfig, etc.

It's my understanding that the Ubuntu subsystem in recent windows is sort of a parallel environment ... but is not meant to control the system directly or as an alternate path of interaction with Windows, correct ?

> It's my understanding that the Ubuntu subsystem in recent windows is sort of a parallel environment ... but is not meant to control the system directly or as an alternate path of interaction with Windows, correct ?

I am not so sure about this. I think Dustin Kirkland sheds some more light here:

http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.htm...

And he seems to be relatively excited about it so he benched it more recently:

https://www.linux.com/learn/howdy-ubuntu-windows-how-fast-it

It seems more like an inverse Wine than a parallel environment.

Alongside is an apt description. It feels a bit like running Linux in a Docker container.

The Windows Subsystem for Linux (WSL) has it's own directory in the Windows filesystem that corresponds to /. It's uses some NTFS magic to store the Linux file attributes that don't directly correspond to NTFS file attributes.

It also, within the Linux environment, mounts your host drives under /mnt.

For what I generally use the OSX terminal for, WSL probably hits about 80-90% of my use cases. A lot of lower level utilities have weird issues - e.g., 'ip addr' seems to present the Windows network interfaces as though they were typical Linux ones, 'ss -a' gives a bunch of netlink errors, dmesg says "dmesg: read kernel buffer failed: Function not implemented", 'tcpdump' doesn't work, etc. On the other hand, curl, scp, ssh, etc do exactly what you'd expect.

My limited experience with WSL gave me the impression that anything that needed /low level/ packet constructs either wasn't mapped correctly or might have required administrative privilege blessing on the Windows side of the environment ACLs.

I hope that these get filled out, at least with more constructive error returns, at some later date.

For now, I'm happy that they have enough of the low hanging fruit ripened sufficiently to make it possible to do 'normal' things from within WSL. I'd honestly rather they make the local (and network) filesystem more performant and robust; maybe they have.

My use case for WSL is coming around in the calendar year again so I'll be revisiting it soon.

The windows drives are mounted as /mnt/c, /mnt/d, etc...

You can call executables in both directions, even use windows executables in a bash script and pipe its output to awk.

https://docs.microsoft.com/nl-be/windows/wsl/interop#invokin...

One of the interesting things is that if Linux developed support for NTFS ACLs you could probably make it pretty seamless. One of the more convoluted parts of the NetApp filer code was the code that allowed for 'mixed' UNIX and CIFS volumes.

We're working on improving integration between Windows and Linux distros on WSL. Stay tuned for progress. The release notes on the WSL doc site [1] are basically our changelog. Highly recommended for the latest updates.

[1] https://docs.microsoft.com/en-us/windows/wsl/release-notes

Full disclosure, I work at Microsoft on WSL.

In the early days there was less interaction but it's getting pretty seamless now.

It's the same kernel underneath so it's not really two parallel systems.

To be completely fair to both sides though, the ability to tweak MacOS from terminal has always felt like it was opposed by Apple. They don't seem to support it officially in any capacity, and in many respects, actively fight it (i.e. changing the preference keys in every single release of MacOS, for literally no reason).

You can do some things to and with MacOS from CLI. Honestly though, it's all stuff I wouldn't miss awfully.

macOS is Unix. That's the big difference for me.

I've been using WSL + wsltty [1] + Xming [2] for months and didn't encounter major issues. wsltty also added support to the Microsoft Store version recently.

For Xming, simply set DISPLAY in shell and local GUI programs just work, as well as SSH X forwarding.

[1] https://github.com/mintty/wsltty

[2] https://sourceforge.net/projects/xming/

(EDIT: typo)

I install OpenSUSE Command line from the Windows Store.

That's all fine and dandy until you want to develop Windows applications using Ubuntu on Windows.

There's still a place for windows native tools.

Have you looked at Mobaxterm at all? I have the same issues, and accidentally discovered this a few years ago, and haven't looked back. Lightweight Cygwin install, own package manager, EXTREMELY usable. The free version is plenty good, but even the paid for version is 'only' $80.

I second this recommendation. It’s a really great tool; I really like the combined SSH and FTP integration so I can browse and edit files with my favorite text editor on the machine I’m ssh’ed into really efficiently while also running commands at the same time.

Also love MobaXterm

I wish Cygwin performed better on Windows, git operations on Linux take minutes on Windows because it has to spin up the whole cygwin environment. This kind of still makes me want to use Linux, but MobaXTerm makes my Windows desktop very usable for administration.

Another "me too!" for MobaXterm. Sessions in tabs, easy file transfer, built-in and automatic X forwarding.

I like PuTTY, and have used it a lot, but MobaXterm has been great.

Neat. I wasn't aware Git client had this much feature. On Windows 10 I have "Bash on Windows", but on older systems (such as Windows 7), Git client would do the trick.

MobaXterm is nice, but I don't like how heavy it is...

WSL has exited beta on the mainline release. You can now install Ubuntu/Suse from the windows store. Look up the processes to extract data from your current wall, unintall the legacy edition and get the new addition. It's not clear yet how the legacy version will be impacted it may be easier to migrate sooner rather than later

You should try WSL with cmder [1], a lightweight windows terminal that feels great and is heavily customizable. It’s the iTerm2 of Windows IMO.

[1] http://cmder.net/

+1 for CMDER, I recommend also following this guide [1] to easily launch linux subsystem for windows on cmder.

[1] https://gingter.org/2016/11/16/running-windows-10-ubuntu-bas...

or just install msys2. Works just as well imo, and can more easily integrate other packages as well.

Yes! OOTB package mgmt...

MSYS2 is highly underated, it works perfectly and I cannot work without it now.

So it's basically a much-improved MinGW or binutils package, is that the idea?

No it's a completely open source, built from source (using gcc) software distribution for Windows. It uses pacman to install packages and comes with many hundreds of prebuilt ones.

It felt like x-mas when I discovered msys. The package management blew my mind. Getting a qt kit set up took about 1 minute.

Great wiki about set up and use here: https://github.com/msys2/msys2/wiki

Msys uses Arch Linux's package manager of all things

Yeah it's not such a mind-blower if you are experienced in using Linux, where this is just common, but it's still really nice to not miss this when working on Windows.

However in the current version of MSYS2 (after an update a few months ago) they suddenly seem to mix the different linux-like distributions and for me it's really hard to choose which shell to use and which package to install for that shell.

Yeah I should clarify, the fact that msys had built in package management was just the most pleasant surprise ever. I use windows when I have to, not by choice. :)

The problem with gitbash is its way slower.

Plus, the real reason you get Putty or SecureCRT if you’re lucky, is because they are actually terminal emulators and not a DOS shell.

Sorry I don’t find Mona compelling at all.

Yeah, but doesn't Putty force you to use it's goofball ssh keys? With git bash you can use regular ssh keys. And, you can generate them the way you're used to (assuming you already use Linux). Idk, I think git bash works just fine in most cases.

It does. But it also comes with a utility that will generate keys, and/or convert regular SSH keys to the format Putty uses.

you can install the tools into your global path so that you can use git's openssh from powershell.

Wow. Way slower? Git bash is just as fast for me. And MUCH more convenient.

I really miss ‘git bash here’ from File Explorer when I’m on my macbook. Why it doesn’t have open terminal here/open iterm here I don’t know. I used to have an AppleScript thing to do it for iterm 2 but it got broke and now all I can find is a button in the finder window.. but it really should be built in.

I'm not entirely sure what you are trying to do, but if you leave the terminal icon in your Dock, dragging any folder from Finder onto it will launch terminal in that directory. Any good?

Nice, works with iTerm2 too - thanks :) I have an iTerm button in Finder which opens it in the current folder, so it's okay - but Windows has right click > open powershell here, and if you have git bash then it has right click > open git bash here - which feels more natural to me. I think the Linux desktops I've used all had right click > shell too.

Instead of ranting, perhaps post your broken AppleScript so we can help you fix that. It really ought to be < 10 lines of AppleScript.

This is what I do too.

I used to use Cygwin but it became a pain to manage the packages and it couldn't update it's own setup.exe last I checked.

I recently tried out WSL and I still run into problems with the file system. My home directory is in a new place which is kind of annoying. And cloning a repo with Git changed all the line endings. autocrlf didn't do anything for me either.

Back to good ol' git.exe

Git Bash is based on msys/mingw which have been around a while. I think both mingw and cygwin will both be deprecated in favor Windows Subsystem for Linux.

I have bash scripts within cygwin that control Windows firewall via netsh interface.

I still can't run those command under Windows Subsystem for Linux.

Wouldn't that be much easier to do with PowerShell? I haven't ever attempted, but I'm assuming...

I use mac, windows, linux, embedded linux all the time. bash/python are just native languages for me.

The powershell's syntax is just too esoteric for me. I did tried that a few times.

Highly unlikely. You'd only deprecate them if they serve the exact same purpose, but they don't. Many users will switch, but not those who want a posix runtime environment for a win32 executable that can run on machines that don't have WSL installed (cygwin, and the fork msys2 which git-bash is based on); or to use the gcc compilers to target win32 executables that use the windows native (non-posix) runtime - mingw. Do you know that you can use gcc to build windows executables and dlls from Linux, Mac, or WSL? That's mingw and it's not going away.

Reply on news.ycombinator.com