Closed Stebalien closed 8 years ago
@cmr when you added the special case for msys, what was your setup? I've cygwin, git for windows, and mingw with mintty but can't find a configuration where MSYSCON is "mintty.exe".
@Stebalien FreeBSD and msys use termcap instead of terminfo? I thought termcap was obsoleted by terminfo.
I'm honestly not sure about that special case! The only reference I can find on the internet is https://github.com/Sharpie/Swarm/wiki/MinGW-wiki, so maybe whatever distribution I was using had a munged bat file.
I see; you modified the batch file (I just launched mintty directly). And yes, they are obsolete.
FreeBSD and msys use termcap instead of terminfo?
FreeBSD uses it's special terminfo system but does include the termcap database.
msys/msys includes /etc/termcap
by default. However, it turns out that mingw has an optionally installable terminfo package. Unfortunately, it gets installed in the mingw root instead of the msys root which is generally mounted under /mingw
in msys (see http://www.mingw.org/wiki/msys). How do you feel about adding /mingw/share/terminfo
to the search path on windows and dropping the msys special case?
MSYS2 sets $MSYSCON
during it's start-up batch file. Other distributions, including Git-for-Windows, don't set this environment variable. The special case doesn't fully work on my machine. See the screenshot below where the color reset is never applied. mintty compatible terminfo files are distributed and are available at the standard location (/usr/share/terminfo
), however term
looks for the files with no knowledge that the process is running in a msys context so the file lookup fails. If you set $TERMINFO
to the Windows path you can get correct colored output. The screenshot below is using mintty distributed with Git-for-Windows.
(Note that Cargo requires running under winpty
because it only checks if it is attached to a Windows console)
mintty compatible terminfo files are distributed and are available at the standard location (/usr/share/terminfo), however term looks for the files with no knowledge that the process is running in a msys context so the file lookup fails.
This makes no sense; we only apply the special case after failing to find the terminfo file. Are you sure that the terminfo files are in /usr/share/terminfo
? That is, could you run ls /usr/share/terminfo
?
The files exist
/s/colors (master *)$ ll /usr/share/terminfo/
total 20K
drwxr-xr-x 1 mike 197121 0 Dec 26 13:45 63/
drwxr-xr-x 1 mike 197121 0 Dec 26 13:45 64/
drwxr-xr-x 1 mike 197121 0 Dec 26 13:45 78/
However the following Rust code will print "/usr/share/terminfo": false
on Windows as it has no knowledge of the path mapping performed by msys/mingw/cygwin.
let path = PathBuf::from("/usr/share/terminfo");
println!("{:?}: {:?}", path, fs::metadata(&path).is_ok());
Damn. I forgot that rust programs compiled for windows wouldn't be able to use cygwin paths. We have a few options:
/usr/share/terminfo
. This is probably a bad idea.Ok. I've changed my mind. This is not the correct way to support all platforms... :disappointed:. For now, I'm recommending that users set the TERMINFO variable but I'll probably end up doing 3 even though it's hacky.
@iliekturtles I believe the first case your reported (MSYSCON=mintty.exe winpty cargo build
) was actually a bug and should be fixed by 6b81bbb472ccbbc2e98211935917a35932636190. Can you confirm? The latest cargo nightly should work correctly.
@Stebalien Success!
This is the correct way to support all platforms. This would fix #44 and would also allow us to correctly support mingw (msys) instead of hardcoding.