Better MSYS2 support

[Diggsey]

Currently only a very minimal set of operations are supported on mys2/cygwin, because it always falls back to msys_terminfo.

However, if it looked in the right place, it would be able to find and parse the correct terminfo: the problem is that it only searches unix-style paths (eg. /usr/share/terminfo) which are not valid for a native windows program.

On windows, it should convert these paths by calling cygpath -w /usr/share/terminfo before it tries to search them. With that modification the additional terminal features should just work.

[Stebalien]

I'm not calling an external binary on any platform. Currently, the best solution is to set the TERMINFO environment variable (see the README). I'm also considering pre-parsing some terminfo databases and including them in term.

[Diggsey]

I don't consider requiring manual intervention by the end-user to be a solution, let alone the best solution.

If you are averse to running an external binary, there are a number of other ways to get cygroot:

• Call the path conversion function directly from msys-2.0.dll/cygwin1.dll
• Use one of the environment variables, for example you can easily figure out the root directory from %HOME%, which will be C:\msys64\home\<username>
• Use the %CYGROOT%/%MSYSROOT% environment variables, falling back to C:\msys64 or C:\cygwin if they don't exist. (This is probably the best option)

Having some common terminfo's built-in would be a good fallback.

[Stebalien]

I didn't know about %CYGROOT%/%MSYSROOT%. I'll look into using those.

[Diggsey]

The problem is that they're not set by the official installer - they're set if you install through some alternative ways, such as via chocolatey, so if you installed to a custom directory that's not C:\msys64, you'd have to set them manually.

[Stebalien]

Link for future reference: https://cygwin.com/cygwin-api/func-cygwin-conv-path.html

Dynamically loading cygwin1.dll/msys-2.0.dll might be the way to go. Do you know how one finds DLLs on windows?

[Diggsey]

You shouldn't need to find them - if the program is run from an msys or cygwin shell then they'll be on the PATH already.

[Stebalien]

Got it. I didn't realize Windows allowed dynamically loading libraries from the PATH at runtime (libraries like libloading expect a full path).

[retep998]

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx#search_order_for_desktop_applications

[Geobert]

Hi there!

Bumped into this from the intelliJ rust plugin, any progress on this?

Cheers!

[Stebalien]

Unfortunately, not really; I don't really have time to learn low-level Windows stuff at the moment. term now has decent support for fallback terminals when $TERM is known but the terminfo database can't be found (so coloring should work) but that's it.

[matklad]

Actually, Cargo recently migrated to termcolor: https://github.com/rust-lang/cargo/pull/4162. So it soon should emit pure ANSI codes for windows, and that in theory should just work with IntelliJ.

[Stebalien]

Isn't this more about rustc error messages than cargo?

[matklad]

Hm, @Stebalien you are probably right! I wonder if it is desirable to remove terminfo parsing from rustc as well...

[Stebalien]

Given fallback terminals, removing terminfo parsing shouldn't be an issue (although that create has a much nicer interface than this one...).

Actually, IMO, the terminfo parser is the one part of this crate that's really worth saving. The pretty-printing API is not fun to use.