Mintty: Support for Windows Subsystem for Linux ✓

[lf-]

I've been attempting to use WSfL, but I've given up on it. It uses the Windows Console host for the terminal, which mangles the output of a few utilities.

It would be great if mintty could replace the default terminal in Windows Subsystem for Linux.

[mintty]

Yes it would, but it's currently not possible; see https://github.com/Microsoft/BashOnWindows/issues/279#issuecomment-216854626.

[edit]

The preliminary solution for cygwin or msys2 users is now documented on the mintty wiki Tips page:
https://github.com/mintty/mintty/wiki/Tips#using-mintty-for-bash-on-ubuntu-on-windows-uow--windows-subsystem-for-linux-wsl

A standalone package will follow.

[Perlence]

I was able to run bash through winpty in mintty 2.4.0, but arrow keys and Home/End did not work. Last time I checked, TERM option in mintty was xterm-256color, but bash resets it to xterm.

[mintty]

Thanks for checking, I hadn't tried that. But I think an application running under winpty virtually has the environment of a Windows console, so you could as well run it in a Windows console. Probably not much advantage of using mintty.

[rprichard]

I was able to run bash through winpty in mintty 2.4.0, but arrow keys and Home/End did not work.

FWIW, I made a couple of fixes to winpty a while ago that may have fixed this problem. For WSL bash, you need winpty version 0.4.0, which has a fix for https://github.com/rprichard/winpty/issues/82. https://github.com/rprichard/winpty/issues/43 is also semi-relevant, but should really only matter for running Cygwin bash under winpty, not WSL bash. I think the MSYS2 pacman package is out-of-date.

That said: now that WSL has real ptys, it should be possible to run a WSL SSH server and login from mintty/putty/etc, which will provide a much better experience than using winpty.

[Perlence]

@rprichard Many thank you! I'll give both ideas a spin soon enough.

[hifi]

You can run sshd with WSL now and you can loopback connect to it with mintty and ssh (I have the cygwin build of both).

mintty certainly seems to work much better over ssh than native PowerShell as I don't hit this missing feature https://github.com/Microsoft/BashOnWindows/issues/741 and there are probably a lot more that I haven't yet tested out. Fixing up PS is probably the route Microsoft is going to take so the mintty approach needs to be community driven.

Would love to have "native" mintty support somehow tied together so that launching mintty would effectively run WSL bash.exe and drop you in the shell without spawning anything extra.

Currently there are 2 extra windows and the loopback ssh server/client setup for this loopback hack to work. One to run Bash on Windows from PowerShell where I start sshd and keep the window open so that WSL doesn't kill sshd and one cygwin related empty console window that opens up with mintty that I couldn't get rid of.

Anyone have any idea what C:\Windows\system32\bash.exe actually does and could it be rewritten somehow tied directly into mintty if we can't run it without PS/cmd.

[Perlence]

@hifi Check this thread discussing how to run sshd as a Windows service https://github.com/Microsoft/BashOnWindows/issues/612

[mintty]

I've just been running Ubuntu bash in mintty with winpty.
It basically works.
UTF-8 works transparently, if another locale is set before starting winpty, it fails miserably (minor glitch).
Cursor keys work, some shifted keypad do not work, mouse interaction does not work!
Many text attributes do not work; bold and ANSI colour works, most notably reverse display does not!

[ewortzman]

@mintty sorry for the silly question, but is this being actively worked on? i.e. can we expect a standalone build of mintty to show up at some point that won't require a full cygwin installation and can replace the windows console? Or is that not in the plan right now?

[mintty]

As my previous comments suggest, I'm certainly interested in such a package. I have not been working on it until the notice (rprichard above) of winpty now being able to fill the gap between the worlds.
I successfully tried this yesterday with a desktop shortcut with
Target: C:\cygwin\bin\mintty.exe -h error /bin/winpty.exe %windir%/System32/uowbash.exe
(or X:\cygwin64...)
Icon: %USERPROFILE%\AppData\Local\lxss\bash.ico

One obstacle is that on my system, the file %windir%/System32/bash.exe is not visible inside cygwin, for unclear reasons (hints welcome) so I had to copy it to .../uowbash.exe first in cmd.exe or Explorer.

I've already compiled a standalone deployment of mintty for another package (my own, actually, the text editor mined) so I can do that for this use case, too. I won't release anything, though, before at least the two major deficiencies mentioned above can be resolved because I don't want to receive lots of complaints that reverse mode or mouse operation does not work.

[hifi]

@mintty I would be very interested in testing it out. If it can handle the missing key escapes that I'm having trouble with Bash on Windows (shifted arrow keys with tmux), it would be more than enough for me to replace my VM at work with mintty + WSL. Colors optional.

[rprichard]

If running an OpenSSH server is too much trouble (understandably), then maybe it'd make sense to write some kind of bridge/proxy that connects Cygwin mintty directly to a WSL pty (e.g. over a TCP socket)? It seems fairly easy to write.

I'll take a look at improving winpty for this scenario, but winpty has to rely on screen-scraping a console buffer, which has limitations. I _am_ surprised that reverse color didn't work, though. I'll look into it.

One obstacle is that on my system, the file %windir%/System32/bash.exe is not visible inside cygwin

My best guess is WoW64 redirection, but I'm guessing you're using 64-bit binaries. (e.g. maybe %windir%/Sysnative/bash.exe would work.)

I've already compiled a standalone deployment of mintty for another package

Is the standalone mintty linked statically with Cygwin somehow? e.g. I thought mintty needed things like fork, exec, pty I/O, select, etc, which Windows doesn't have natively.

[hifi]

Running an OpenSSH server with the console window open wouldn't be that much different if the console window needs to be open anyway. Ideally you would launch mintty and it would run UoW bash.exe without requiring more open dummy windows. If this can't be avoided externally, the system32 bash.exe needs to be replaced.

[mintty]

One obstacle is that on my system, the file %windir%/System32/bash.exe is not visible inside cygwin

My best guess is WoW64 redirection, but I'm guessing you're using 64-bit binaries. (e.g. maybe %windir%/Sysnative/bash.exe would work.)

Thanks for the hint, I was in fact using cygwin32 (WoW) and it's visible from cygwin64. I wonder why and how this WoW thing hides files, yet another MS miracle...

For that other project, in fact I link mintty statically to reduce the set of libraries to be deployed but it still needs cygwin1.dll which cannot be statically linked unfortunately (or msys2.dll would work alike).

[mintty]

[back in 10 days]

[Perlence]

I was in fact using cygwin32 (WoW) and it's visible from cygwin64. I wonder why and how this WoW thing hides files, yet another MS miracle...

I find this confusing as well https://msdn.microsoft.com/en-us/library/windows/desktop/aa384187.aspx

[mintty]

Thanks for the info.

[rprichard]

... then maybe it'd make sense to write some kind of bridge/proxy that connects Cygwin mintty directly to a WSL pty (e.g. over a TCP socket)? It seems fairly easy to write.

I hacked up something tonight that uses a TCP socket to bridge the I/O between the Cygwin and WSL ptys. It basically works, but I need to polish it; I'll publish it in a day or so. There is a Cygwin "frontend" program and an Ubuntu "backend" program in the same directory. The frontend spawns the backend using CreateProcess and CREATE_NO_WINDOW, which hides the Ubuntu bash console window.

[hifi]

Awesome!

[rprichard]

I hacked up something tonight that uses a TCP socket to bridge the I/O between the Cygwin and WSL ptys.

My project is at: https://github.com/rprichard/wslbridge

It compiles to two binaries, wslbridge.exe and wslbridge-backend. The backend executable must be on a local NTFS filesystem so that it's accessible via /mnt/<DRV>. (Maybe that's a problem for mintty? e.g. It won't run on an network share. The backend would have to be copied locally first.)

It works a bit like ssh without the hostname. A command-line is optional; if specified, it defaults to pipe communication instead of pty, but there are -t, -t -t, and -T options for controlling that, as with ssh. It also has an -e option to import/set environment variables.

I can run a WSL mintty session with a command like:

c:\cygwin64\bin\mintty /cygdrive/c/rprichard/proj/wslbridge/out/wslbridge

[hifi]

@rprichard Could you provide binaries as GitHub releases for easy testing?

[mintty]

Does the wslbridge-backend correspond to the winpty-agent? If so, why would it need to be installed inside WSL while winpty-agent does not? This is indeed a problem for a plug-and-play deployment.

[mintty]

mintty /cygdrive/c/.../out/wslbridge

fails here with error while loading shared libraries: ?: cannot open shared object file: No such file or directory

[Perlence]

@rprichard @mintty Works fine for me on MSYS2 :+1:

[rprichard]

Could you provide binaries as GitHub releases for easy testing?

@hifi Yeah, I can provide binaries.

Does the wslbridge-backend correspond to the winpty-agent? If so, why would it need to be installed inside WSL while winpty-agent does not? This is indeed a problem for a plug-and-play deployment.

@mintty The wslbridge-backend plays a similar role as the winpty-agent, but it doesn't work the same way at all. The winpty-agent is a Win32 console program that scrapes a screen buffer using Win32 APIs (e.g. ReadConsoleOutput), whereas wslbridge-backend is an ELF64 Linux program similar to sshd/telnetd. wslbridge.exe runs %WINDIR%\System32\bash.exe -c '/mnt/<path-to-backend> <backend arguments>' to start wslbridge-backend.

fails here with error while loading shared libraries: ?: cannot open shared object file: No such file or directory

@mintty I think it's looking for Cygwin/MSYS2 DLLs and not finding them. Assuming so, it can be fixed by:

1. placing wslbridge.exe in the same directory as cygwin1.dll/msys-2.0.dll or
2. changing the starting directory to the one with the Cygwin DLLs, or
3. adding the Cygwin directory to the PATH.

I created a shortcut using fix 2, but I still wanted to change the WSL starting directory, so I used this command:

• Target: C:\cygwin64\bin\mintty.exe C:/rprichard/proj/wslbridge/out/wslbridge -t bash -c "cd ~ && bash"
• Start in: C:\cygwin64\bin

[rprichard]

@hifi I uploaded binaries at https://github.com/rprichard/wslbridge/releases/tag/0.1.0. I compiled the frontend for x86 and x64, Cygwin and MSYS2. The backend is the same ELF64 binary in all 4 packages.

[hifi]

@rprichard I've now given it a whirl and it seems to work wonders. Performance is excellent and all the missing features of PowerShell that bothered me work just fine with mintty now. Great work!

This might be just in my head but it seems to perform better than mintty with cygwin bash regarding screen updates when using curses stuff over ssh.

[goreliu]

I made a package called wsl-terminal (https://github.com/goreliu/wsl-terminal), contains Cygwin DLL, mintty, wslbridge, cbwin and some tools I wrote.

With it, we can run mintty + wslbridge from explorer.exe context menu (work with tmux, open a directory in a new tmux window), run .sh/.py/.pl scripts in WSL, edit files with vim in WSL, run Windows .exe/.bat in WSL and so on, no need of installing Cygwin or MSYS2.

[rornor]

Very beautiful, such pleasure...

Thanks people for making this happen so quick

[mintty]

I reviewed the wsl-terminal package; first, many thanks for doing this. I added a bunch of comments in https://github.com/goreliu/wsl-terminal/issues/2#issuecomment-242170124.

About my proposal to use an overlayed icon, in order to avoid copyright issues, it might be useful to generate it dynamically. If someone can provide a patch or code snippet how to do that in Windows, I would like to add such a mintty feature.

[mintty]

@rprichard: Many thanks for this essential program. I just notice that wslbridge-backend doesn't even have to be installed inside WSL which enables seamless integration.
Questions: How does the 32-bit version of wslbridge work as it cannot see $SYSTEMROOT/System32/bash.exe?
How would I start a login shell in my WSL's home directory?
Option -T does not seem to work here.
Also, it might be useful to have it as a cygwin package; either you or me might package it, or actually both wslbridge and winpty.

[rprichard]

@mintty Yeah, the backend doesn't need to be installed, so long as the frontend can get some kind of WSL path to the backend. Currently, it always uses the /mnt/<DRV> paths, which only exist for NTFS volumes mounted on letter drives. Currently, the frontend takes the wslbridge.exe module path, then converts it to a WSL path in the obvious way, by converting the drive X: to /mnt/X and converting backslashes. It doesn't enforce the NTFS requirement currently -- maybe it should somehow. (It just occurred to me that I should test things like NTFS junctions and symlinks, and I _think_ Windows also allows mounting a volume in an empty directory. It wouldn't surprise me if some/all of these didn't work.)

There is another potential issue -- the wslbridge-backend file must be executable within the WSL filesystem. If the backend lacks the Execute NTFS permission, then it also seems to lack the WSL Unix execute bit (and then WSL refuses to run it). I think this shouldn't be an issue, because if wslbridge.exe has the Execute permission, then the backend probably will, too. The fact that it isn't an executable Windows program doesn't seem to matter. (However, I was careful to use Cygwin tar instead of MSYS2 tar when packaging wslbridge, because MSYS2's POSIX emulation always considers the backend non-executable. [source])

The 32-bit wslbridge looks in $SYSTEMROOT/Sysnative, then $SYSTEMROOT/System32. The 64-bit binary only looks in $SYSTEMROOT/System32. [source]. Perhaps the 32-bit version could look only in Sysnative, but Sysnative doesn't exist when the redirection is turned off, and I was worried that something could turn it off. Maybe I don't need to be?

The wslbridge -T option does the same thing as ssh -T: it forces the use of pipes rather than a pty. The -t option enables the pty. I think the shortcut target at the bottom of my previous comment should work? I noticed that when I ran the official "Bash on Windows" shortcut, it didn't pass -l to the WSL /bin/bash process, so I also made wslbridge invoke /bin/bash without -l by default.

I think both winpty and wslbridge should be packaged for Cygwin -- I think I'm planning to package winpty at some point (https://github.com/rprichard/winpty/issues/64), but I don't know when. I suppose once I do that, I'll work on wslbridge packaging at the same time.

[lapo-luchini]

C:\cygwin\bin\mintty.exe C:/Users/lapo/Works/wslbridge/out/wslbridge -t bash -c "cd ~ && zsh"

…this made my day, thanks!

[mintty]

The preliminary solution for cygwin or msys2 users is now documented on the mintty wiki Tips page:
https://github.com/mintty/mintty/wiki/Tips#using-mintty-for-bash-on-ubuntu-on-windows-uow--windows-subsystem-for-linux-wsl

A standalone package will follow.

[rprichard]

A few comments:

1. The preliminary solution directs the user to install wslbridge, but then the shortcut points to winpty.
2. As far as I can tell, the WSL bash -l option doesn't actually set the working directory to the home dir. It merely changes the startup script (to ~/.bash_login, I think). I tested by starting cmd.exe, then running bash.exe -l in various directories.
3. > Install wslbridge.exe and wslbridge-backend into your /bin directory

Users have two /bin directories--one for Cygwin/MSYS2 and one for WSL. It's not strictly necessary to install into /bin at all, but I can see how it simplifies finding cygwin1.dll/msys-2.0.dll. (I'd probably install into /usr/local myself.) I think it'd help to prefix "Cygwin/MSYS2" before /bin in the instructions.

1. Most of the comments about 32/64-bit architecture don't apply to wslbridge. Architecture matters in two ways:

a. The user must pick the right wslbridge archive.
b. The user must select the correct Cygwin/MSYS2 root (X:\cygwin vs X:\cygwin64, X:\msys32 vs X:\msys64).

The wslbridge.exe frontend handles the Sysnative vs System32 difference internally.

[mintty]

Oops, a bunch of flaws at one strike, and I completely confused winpty with wslbridge. Sorry and thanks for the quick review, I hope I've fixed everything now.
Yes, bash -l does not land in your home directory natively, but it does by typical default configuration profile scripts. Installing into /bin saves an additional installation caveat; /usr/local does not even exist on a typical plain cygwin installation.

[rprichard]

The target is:

X:\cygwin64\bin\mintty.exe /bin/wslbrigde.exe -t /bin/bash.exe -l

It should be:

X:\cygwin64\bin\mintty.exe /bin/wslbridge.exe -t /bin/bash -l

That is:
(1) s/wslbrigde/wslbridge/
(2) The /bin/bash is a WSL path, so there's no exe suffix.

Otherwise, looks good to me.

[mintty]

Thanks once more; and changed the heading for consistency within the page, thus also the link.

[mintty]

Uploaded a package with an installer, see https://github.com/mintty/wsltty/releases

[sebmaynard]

@mintty amazing! Thank you

[green-s]

@mintty How would you go about adding a context menu launcher for wsltty? It doesn't have chere or xhere. I tried copying xhere from cygwin but I got a "no such directory" error on launch.

[mintty]

I intended to provide something basic and not compete with the wsl-terminal project which has some more enhancements and add-ons but also needs some configuration and doesn't have an installer (yet), I think.
But maybe context menu is sufficiently basic to add it...

[mintty]

Polished wsltty package and released 0.5.

[mintty]

Option --dir has been added for the sake of registry entries that start mintty from the Explorer context menu, considering that shells, like dash (currently used to change directory) do not handle non-ASCII directory names properly in this context.

[mintty]

Released option --dir in 2.6.2.

[mintty]

Released wsltty 0.6.2. Works in context menu of non-ASCII folder names (thanks to new mintty option).

[mintty]

Hi James,
this is interesting information. I wonder why the comment is not shown
on the issue page, did you delete it?
Anyway, this reads like a design concept and doesn't seem available yet (?);
I'd appreciate to receive further hints on how to actually setup an
interoperable development environment.
Thanks
Thomas

With the most recent release of WSL they have added interop between
native Windows and Linux executables via LxCore.sys
https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-ubuntu-interoperability/
I am not hugely knowledgeable on this subject but I would love for
mintty to work as a terminal for WSL. Console Host really is not that
good compared to mintty. If this can help make that happen that would
be awesome.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mintty/mintty/issues/558#issuecomment-255571918,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMJnQIraTomj4YRmJ0BDt1-eUjNQmnasks5q2vxVgaJpZM4Isk2I.

[Sparkx120]

Hi Thomas,

Yea I noticed that the thread was already closed after I commented and saw that a solution had been posted so I thought I should erase my comment. What I was referring to was this: https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-ubuntu-interoperability/

It is implemented on the latest build of Windows. I have build 14951 on my computer and can execute Windows software from the Ubuntu shell through this system. It seems the ability to instantiate a bash session without the Command Host may be possible now and that it could instead be connected directly to a mintty instance which would be much preferred. Sadly I have not had much time to mess around with it but I had hoped it would spur ideas for the mintty developers.

Thanks and Cheers,

James

[mintty]

Hi; well, this issue isn't closed (there's a reference from another closed issue) and even closed issues accept discussion...
Anyway, as said before, I'll be waiting until this becomes clearer (installation available etc).

[Sparkx120]

Ah I see now. Sorry I don't usually say much so I wasn't quite sure what the etiquette was. Trying to get more involved in the open source community.

[mintty]

Can wsltty be built from inside bash for linux, or does it need to be from inside a cygwin environment?

The mintty terminal is a cygwin application (its installation comes with a small stand-alone installation of cygwin), so yes, cygwin is needed to compile it.
WSL-native compilation of mintty would require WSL support of the Windows APIs which was not a feature when I checked it.

[mintty]

Mintty 2.8.0 simplifies WSL integration (even from the session launcher of the cygwin version).
WSLtty 1.8.0 provides a package with optimized support for WSL distributions as now available from the Windows store.