"cygwin" terminal support

[nsf]

"cygwin" terminal support

[nsf]

Can you please try: TERM=xterm ./keyboard

Most likely cygwin has compatible xterm termcap (like most terminals). And if it is that way, I will add it to the lib. On the other hand I'm not sure it will work on windows at all. But we'll see.

[thejoshwolfe]

TERM=xterm made it work pretty well. None of the Ctrl+number combinations worked, although they were reported as overloads of other combinations (such as Ctrl+3 == Ctrl+[). I didn't test everything thoroughly, but it did run.

[thejoshwolfe]

Another thing to note is that the terminal emulator in this scenario is truly cmd.exe, not anything made by cygwin. I'm guessing cygwin defines the TERM variable because unix expects it, but cygwin actually has no idea what terminal emulator it's running in. When running cygwin's bash inside an alternative terminal emulator for windows called Console 2, $TERM is still "cygwin". That makes "cygwin" as a $TERM value effectively unreliable, but it still seems prudent to assume "cygwin" means cmd.exe.

[nsf]

None of Ctrl+number are supported. See NOTES file for partial explanation. I'll add "cygwin" terminal type now as an xterm compatible terminal.

[thejoshwolfe]

more things that don't line up in cygwin:
F1 is 'A'
F2 is 'B'
F3 is 'C'
F4 is 'D'
F5 is 'E'
up arrow is 'A'
down arrow is 'B'
right arrow is 'C'
left arrow is 'D'
home is ''
end is ''

The following:
F6-F12, page up, page down, insert, delete
intermittently register as ''. Intermittently as in, keep pressing F7 repeatedly and it will switch between F7 and '' erratically. It looks like this is all the "Key" inputs as opposed to the "Char" inputs except for escape, tab, and backspace. Those 3 are reliable.

This behavior is identical in both cmd.exe and Console 2.

[nsf]

So it's not xterm compatible, I'll see what I can do, but it may take some time..