Problems when running under cygwin+mintty

[trptcolin]

There's a report at technomancy/leiningen#850 of this issue on Windows + cygwin + mintty, which sounds like it's not detecting the need for UnixTerminal. @orfjackal has included a workaround that fixes things for him, but it seems like ideally this would be done by jline so that projects using jline don't all have to do the same workaround.

I haven't reproduced this locally yet, but I thought I'd remembered seeing things work as expected in cygwin. Could just be mis-remembering, because the terminal selection code appears to be only based on OS name.

Thoughts?

[gnodet]

Good question, I'm not sure we ever had anything for cywin specially.
One thing I'm wondering about is how terminal settings would work in cygwin when calling stty for example.

[luontola]

About detecting that we're inside cygwin:

It might be possible to analyze the enviroment variables from System.getenv() to get hints that whether we are in a unix-like environment. I ran the following program in Windows both under and outside Cygwin:

import java.util.*;

public class Test {
    public static void main(String[] args) {
        SortedSet<String> names = new TreeSet<String>(System.getenv().keySet());
        for (String name : names) {
            System.out.println(name + "=" + System.getenv(name));
        }
    }
}

Unfortunately the Java process doesn't have the OSTYPE variable under Cygwin, even though echo $OSTYPE shows it, but maybe it's possible to analyze the other variables. For example the presence of a PWD or TERM variable when the OS name is Windows. Another way might be to check whether the stty program exists. Also I wonder if the TERM variable is something that universally identifies a terminal, so that it would not even be necessary to check the OS name?

BTW, I noticed in TerminalFactory.java that the line if (System.getenv("TERM") == "dumb") has a bug. Strings must be compared with equals: if ("dumb".equals(System.getenv("TERM")))

[jdillon]

@orfjackal ya its clearly a bug from 1fd2559 :-(

[trptcolin]

My fault. Pushed a fix: 6f69925

[trptcolin]

Gah, that's no good either, in case it's null. Fixed in cf01c35

[trptcolin]

Sorry for taking so long to get back to this. The option I like best is to look at TERM, and assume that a non-null, non-empty TERM means we want a UnixTerminal. (It's really unfortunate that OSTYPE isn't exported by default)

We could also check for a slew of specific TERM values like xterm, xterm-256, vt220, etc, but leaving it generic seems like a cleaner solution.

Thoughts?

[trptcolin]

Unfortunately, in my VM testing, even using a UnixTerminal doesn't work for my cygwin/mintty setup. Using -Djline.internal.Log.trace=true, I see the keybindings being triggered, but things don't work properly, which is due to this error: sh: /dev/tty: No such device or address when jline tries to do any stty commands.

So for now, making the stty calls before and after running jline's code (as @orfjackal and http://weblogs.java.net/blog/cayhorstmann/archive/2010/11/24/report-sewer-hole-cygwin-jline-rxvt-and-scala-repl describe) - is the only working solution I've got, and that still puts the onus to handle this on consumers of jline.

Hopefully someone with some Cygwin knowledge can figure out why /dev/tty is inaccessible from our subprocess and a way to fix it?