Subject: Re: CVS commit: basesrc/bin/ksh
To: NetBSD Userlevel Technical Discussion List <firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 09/29/2002 11:54:31
>>>> The NetBSD console gives ^[[8~ for <END> not ^[[F
>>> A, well then I guess on some versions of NetBSD, including what
>>> you're using, the console is not ANSI x3.64 compatible.
>> I'm fairly sure that X3.64 specifies [output] and has nothing
>> whatever to do with [input]
> I don't have the full X3.64 spec., but I do know that the cursor keys
> in ANSI mode are expected to generate <ESC>[A and so on.
Certainly. But this is from historical convention, not because they're
specified as such in X3.64. X3.64 specifies that CSI A (ESC [ A, in
7-bit form) is CUU, Cursor Up, on output; I assume the designers of the
VT-100 made the up-arrow key generate the same sequence out of the
notion that the up-arrow key should generate a sequence that on output
moves the cursor up (not an unreasonable point of view).
Or perhaps there's some other standard that specifies sequences
generated by keystrokes. (Or perhaps I'm wrong about X3.64, even.)
> In general I've always understood it to be that the expectation is
> that the keys will generate whatever sequence would be necessary to
> have the expected effect on the display when a loopback is connected
> to the data port.
Yes, and as I said above, it seems like a reasonable expectation to me.
But I'm fairly sure it's got nothing to do with X3.64 compatability,
which is all I was taking issue with when I chipped in (see the
third-oldest quoted fragment above).
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML email@example.com
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B