> On 6/2/2009 9:28 AM, Ken Brown wrote:
> > On 6/2/2009 8:48 AM, Corinna Vinschen wrote:
> >> On Jun 1 17:03, Ken Brown wrote:
> >>> The Cygwin console, after some changes made this past weekend, now
> >>> uses ^? as the default erase character, and this is what is sent by
> >>> the backspace key instead of ^H
> >>> [...]
> >>
> >> What makes me a bit concerned about this change is that, while we can
> >> change Cygwin's terminfo and termcap files, we can't do that for
> >> existing non-Cygwin installations. Is it really safe to change the BS
> >> key to ^? now that the "cygwin" terminal type is known to return ^H for
> >> so many years?
> >
> > Applications like emacs that use ncurses should have no problem. Are
> > there applications that rely on the historical behavior of the cygwin
> > terminal type rather than querying terminfo? Apart from cygwin, such
> > applications would have problems with any terminal type that decides to
> > change its behavior.
> Sorry, I think I misinterpreted what you meant by "non-Cygwin
> installations". But wouldn't the issue be resolved by pushing the
> change to the cygwin terminal type in terminfo upstream?
If it were about termcap/terminfo, it must be expected that an upstream change
would take years until it propagates to most actual installations, which means
years of inconsistent default configuration for remote login from
cygwin console...
On the other hand, with this specific setting, the dreadful backspace issue,
it is more crucial that the setting of stty is consistent with what the
terminal
actually sends. So of course it needs to be made sure that this works
within cygwin. -
About remote login, it should be noted that Linux systems (some at
least) as well as SunOS seem to be assuming "stty ^?" on remote login,
which is obviously not proper behaviour (especially if termcap says something
different), but that's what I see. So in that respect, typical
configuration is not consistent right now and would become consistent
by this change.
2009/6/2 Corinna Vinschen:
> On Jun 2 11:39, Christopher Faylor wrote:
> > > On Tue, Jun 02, 2009 at 05:33:27PM +0200, Corinna Vinschen wrote:
> >> > >Maybe it is, that's why I'm asking. But, if we do that, shouldn't
> >> > >Ctrl-Backspace return ^H as in xterm? So far the Cygwin console
> >> > >returned ^H without and ^? with Ctrl, now it returns ^? in both
> >> > >variations.
While it is true that the xterm resource "backarrowKey" would set this
to ^H by default, most actual Linux installation change it by common
configuration.
> > > IMO, cygwin's console == linux console. On two of my systems (Fedora
> > > and Gentoo) CTRL-Backspace returns Backspace on the console. Now that
> > > I'm at work, I see that CTRL-Backspace returns ^H on my Ubuntu system.
> > > But, so far, the CTRL-Backspace == Backspace contingent is winning.
>
> Uh, oh, hmm. I was always under the impression we try to be as xterm
> compatible as possible, rather than the Linux console.
Checking escape sequences of function keys and keypad keys, there are
many similarities (and common deficiencies) with Linux console and
some weird differences:
* Linux console (SUSE, don't know if it's really consistent) defines
function keys F1...F12 and Shift-F1...Shift-F8 (very weird to stop here).
* Cygwin console Shift-F1 and Shift-F2 are identical to F11 and F12,
I don't think that's intended, I guess it should also be changed
on the occasion of revising the console.
* Cygwin console has shifted function keys up to Shift-F10, no F11/F12.
* No Control-/Alt-modified function keys (on either console).
* No Control-/Shift-/Alt-modified keypad keys (i.e. cursor keys, Home etc);
I would very much appreciate if this gets improved, too.
* Cygwin console lacks one feature that is quite useful: cursor position
reports. On output of ^[[6n, the terminal should respond an escape
sequence encoding the current cursor position.
> 2009/6/3 Corinna Vinschen:
> > Even not knowing the sequence returned by Alt-Backspace, AFAICS, the
> > right thing to do is to send either ^[^? or \377, dependent on the
> > setting of dev_state->metabit.
> I think that's the right thing to do. I'd pointed out the problem with
> Alt+Backspace, but that got lost in the discussion about my suggestion
> to have Ctrl+Backspace send ^_.
> The keycode probably doesn't show up in od output because the pseudo
> terminal device interprets the ^? for line editing purposes.
Not quite the pseudo terminal. It's the readline function (of bash, cat, ...)
so obviously ^? rubs out the ESC again as it should.
> Attached
> is a small program I use for echoing keycodes, which puts the terminal
> device into raw mode. Quit with ^D.
The following would also serve as a quick test:
stty raw; od -t x1
By the way, I've always wondered why I cannot use "cat" for a quick test
of most keyboard escape sequences in cygwin. This works quite nicely in
Linux (except for the case above, apparently). On cygwin, entering cursor
keys to "cat" just lets the cursor wander around, while on Linux it echoes
the escapes; if I rlogin to a Linux box from a cygwin console, it works as
well so I am puzzled what the difference is. Just curious, in case someone
has an explanation...
Ken Brown wrote:
> ... But it does seem that the release of 1.7 is a good time to decide
> whether the cygwin console is emulating linux or xterm or something else
> and then make this happen as much as possible.
I would suggest not to follow such a strong plan ("as much as possible");
xterm has a lot of features, not all are really useful, and it has some
deficiencies, too. I've just had a lengthy discussion with Andy Koppe about
various issues..., just a few examples:
* "Application Cursor and Keypad Modes" - a dreadful heritage of VT100/VT220
which raises much confusion and inconsistencies between terminals, although
properly used it also provides the opportunity to distinguish as many key
and modifier combinations as an application wishes, with some unfortunate
limitations, though.
* Advanced mouse modes. Actually, it would be nice for cygwin console to
support mouse wheel scroll reports (in current mode "1000"), plus mouse
movement reports (in mode "1002"), plus ...?
* VT100-mode line drawing graphics. These are used by many programs for
graphic lines and menu borders.
Cygwin console supports VGA mode graphics instead (like Linux console)
with the problem, however, that the actual graphic symbols displayed
would change with the DOS codepage that you can set with e.g. the CHCP
command...
Thomas
