Problems in mintty/cygwin

[jmahood]

Hi, I found my way here after diagnosing a problem in redis-cli.exe, built with gcc/x86_64-pc-cygwin/4.8.2. I'm running this in the mintty terminal (cygwin's xterm emulator), inside of gnu screen (but same issue outside of screen with TERM=xterm, etc).

I tried out the example.c client and see the same issues which are:

Issue A) linenoisePrompt writes the prompt at the previous line's last column.

Here is me pressing enter several times:

%>echo $TERM
screen-256color
%>./example.exe
hello>
       hello>
              hello>
                     hello>
                            hello>

While this problem goes away if I set TERM=dumb, so do most of the nice features.
I've tried using various TERM settings, and I've done a little debugging....

When I hit enter, it looks like printing "\n" is only causing a NL without a CR... if I step inside of linenoiseRaw, before the prompt is written, I can clearly see my cursor has moved down a line, but has not jumped back to column 0, and this is the place where the next line's prompt starts.

I don't know the termios apis that well, but I did a little poking around. If it helps, here is are my termios structs:

orig_termios = {
  c_iflag = 0,
  c_oflag = 0,
  c_cflag = 6306,
  c_lflag = 0,
  c_line = 0 '\000',
  c_cc = "\000\017\000\000\004\177\003\025\026\001\034\022\021\023\032\032\000\027",
  c_ispeed = 15,
  c_ospeed = 15
}
raw = {
  c_iflag = 0,
  c_oflag = 0,
  c_cflag = 6322, // The only actual change...
  c_lflag = 0,
  c_line = 0 '\000',
  c_cc = "\000\017\000\000\004\177\003\025\026\001\034\022\021\023\032\032\000\027",
  c_ispeed = 15,
  c_ospeed = 15
}

The only change here is the application of CS8, which has no effect if I don't change it. I also tried out some different combos of iflags and oflags, and can fix the problem with ECHO enabled, but that pretty much cripples every other feature.

I think the best fix is to explicitly move the cursor to column 0 before writing the prompt. Since you already use the ANSI CHA (Cursor Horizontal Absolute) escape sequence elsewhere, it seems like a sane thing to use here.

In linenoisePrompt, I changed:
    if (write(fd,prompt,plen) == -1) return -1;
to
    if (write(fd,"\x1b[0G",4) == -1) return -1;
    if (write(fd,prompt,plen) == -1) return -1;
or alternatively you could just call refreshLine with the prompt and empty buffer.

...and this fixes this issue for me. Perhaps there's a termios solution, but this seems like a simple enough catchall, assuming that the ANSI CHA sequence is working in general.

Issue B) arrows do not work.

When I press my up/down/left/right arrow, I just see an A/B/D/C character written to the terminal.

In the debugger, for up arrow I see the following sequence being sent:
(unsigned char) 27, 91, 153, 65
This is rather strange, because everywhere else I test it, mintty sends the usual 7 bit escape sequences for arrow keys:
(unsigned char) 27, 91, 65

It's only in this particular raw mode, it seems, where I get this 153 unsigned char in the mix. So, what is that 8 bit (153 / \231 / 0x99) character doing in there? Again, I tried not setting CS8 in raw.c_cflag, but that causes no change in what I'm seeing.

I'm really baffled by this one. If I run this example.exe build in a windows cmd.exe console, arrow keys work fine. And again, everywhere else I try mintty like at a bash prompt Ctrl-V,arrow_key, cat | xxd,arrow_key, with the exception being in vim where application key codes are sent like 27, 79, 65, which is normal.

I'd suggest someone else testing this in a cygwin/mintty setup to rule out that it's just something odd about my host machine / env. Thanks.

[tgaillar]

No, this is a CYGWIN issue (I investigated it in deep) where TCSAFLUSH in tcsetattr() is likely not properly honored (TCSAFLUSH = flush tty before new attributes are being set).

Forcing a flush() followed by a usleep() delay before calling tcsetattr() apparently fixes the issue... (but what a kludge!).

CYGWIN developers shall be made aware of this at some point.

[cxw42]

Prompts and arrows work fine for me on Cygwin x64 (Win8.1) --- I suspect this was an upstream issue that has now been fixed. @jmahood are you still encountering this problem?