On Thu, Feb 28, 2002 at 03:26:38PM +0100, Erika Pacholleck wrote:
> When doing some experimenting with the acm/screen maps I discovered
> some strange things, as to not-working and vice-versa-working. And
> I would need an advice where to hook in for fixing, please.
>
> system information:
> - running linux-2.4.10, compiled with/against 2.4.5
> - kbd-1.06, ncurses-5.2
> state after system start:
> - with matrox fb
> - with keymap de-latin-nodeadkeys
> - without font loading/changing
> - and $TERM=linux
> - and dumpkeys saying 0x000f=control_o 0x000e=control_n
> - and inputrc allowing 8-bits
> - and locale charmap as ISO-8859-1
So far so good.
> expected behaviour from this:
> - G0 set to default latin1 and G1 set to VT100 graphics
> - typing [Ctrl]+[o] sending Control_o (switch to G0)
> - typing [Ctrl]+[n] sending Control_n (switch to G1)
Expected behaviour where? You can't expect terminal applications (I assume
you were using the shell here) to just echo every character they receive to
the terminal. That defeats the whole point of keyboard handling. For
example, a lot of programs, upon receiving ^L, while redraw the screen, and
not send that character to the terminal. A notable exception to this is
cat(1), which will just echo at its output whatever it receives in its
input. In fact, cat is very useful for tests like this.
> here is what happens in reality:
> docs hit keys echo -e orders
> SI=G0=^O [Ctrl]+[o] \\033o \\x1bo \\x0e \\016
> SO=G1=^N [Ctrl]+[n] \\033n \\x1bn \\x0f \\017
> results negative neg. neg. both switched
>
> Ctrl+o looks like CR is sent; Ctrl+n beeps
As I said, just because you press ^N or ^O at the bash prompt, doesn't
mean that it will echo them to the terminal. Use cat and it will do what you
expect.
> \\033o \\x1bo and according n's don't show any change
These sequences are ESCn and ESCo, completely different from the control
characters you are talking about.
> \\x0e \\016 look like switched to G1 VT100 graphics
> \\x0f \\017 look like switched to G0 latin1
>
> So only echoing the hex/oct values seem to get at least the G0/G1 maps
> -- only that they now are just the other way round than it should be.
Actually, the values you are using should be the other way round, as ^N is
ASCII 14 and ^O is ASCII 15. As a rule of thumb, the ASCII value for ^X,
where X is any letter of the english alphabet, equals the position of that
letter in the alphabet.
> And there seems to be no program to report the status (like say, tty2:
> using G0, currently set to latin1) so I can only judge from what I see.
Indeed, if there is a way I'm not aware of it.
> I guess the keymap will need change to make the key-hitting work the
> way it should be, but what do I check for the vice-versa 0e/0f signal?
>
> Thanks for your comments.
To summarize, remember that ^N and ^O, like most other codes, change the
state of the terminal when they are output to it, not when they are input
from it.
--
Vasilis Vasaitis
[EMAIL PROTECTED]
"Don't do drugs. Santa Claus is watching."
-- winamp.com
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
