Re: SI/SO G0/G1 in linux console
SI/SO G0/G1 in linux console doesnt work, or at least what it does is not at all according to what vt100 does or ECMA says. For precise details, see the Keyboard and Console HOWTO (http://www.win.tue.nl/~aeb/linux/kbd/kbd-6.html) and manpage console_codes(4). From: Erika Pacholleck [EMAIL PROTECTED] 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. 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) and indeed, that is what I find. here is what happens in reality: docs hit keysecho -e orders SI=G0=^O [Ctrl]+[o] \\033o \\x1bo \\x0e \\016 SO=G1=^N [Ctrl]+[n] \\033n \\x1bn \\x0f \\017 resultsnegative neg.neg. both switched Ctrl+o looks like CR is sent; Ctrl+n beeps \\033o \\x1bo and according n's don't show any change \\x0e \\016 look like switched to G1 VT100 graphics \\x0f \\017 look like switched to G0 latin1 what you are testing is your shell rather than the console settings. Andries -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: SI/SO G0/G1 in linux console
SI/SO G0/G1 in linux console doesnt work, or at least what it does is not at all according to what vt100 does or ECMA says For precise details, see the Keyboard and Console HOWTO (http://intuenl/~aeb/linux/kbd/kbd-6html) and manpage console_codes(4) Can you try out the dave jones tree I have rewritten the VT emulation support and I like to see if I implemented correct behavior -- Linux-UTF8: i18n of Linux on all levels Archive: http://mailnllinuxorg/linux-utf8/
Re: SI/SO G0/G1 in linux console
Can you try out the dave jones tree I have rewritten the VT emulation support and I like to see if I implemented correct behavior Today we have some vaguely vt100-like behaviour described by TERM=linux Do you think we need a kernel that supplies TERM=vt100? Andries -- Linux-UTF8: i18n of Linux on all levels Archive: http://mailnllinuxorg/linux-utf8/
Re: Meta vs. Alt
On Wed, Feb 27, 2002 at 07:24:22PM +0100, Erika Pacholleck wrote: [260202 21:27 +0100] Radovan Garabik -- : before Alt, there was Meta Hehe, wasn't that one beginning: Once upon a time long before Alt, So when the first keyboards were made we really had a key which had printed Meta on it, and later people thought Meta is not understandable, so we print Alt on the key (so to say, this is a key which will assign totally alternate/different meaning to the second key which I press with it), correct? exactly If Meta prefixes a character with ESC this would mean that for example ESC ( K would be equal to Meta_parenright K and if I have a line alt keycode 9 = Meta_parenright (Meta_ = ESC prefix in front of) then typing [Alt]+[(] [k] should do G0 to userdefined ? yes something like that Nice thing is that Meta can be replaced with pressing ESC erm, here should have been a linebreak Alt, to give the keys _yet another_ control function That's now really too high for me, if I press the [Esc] key I expect it to send ESC (0x1b ^[) which is a single action and [Alt] would be pressed alone and it does not do anything And if I press [Alt]+[Esc] the alt part would prefix the next with escape, so it would result in ESC ESC equal to Meta_Escape -- ifff all my above understanding was correct if alt_is_meta then yes alt should not be meta, however, if it can be achieved -- --- | Radovan Garabik http://melkordnpfmphunibask/~garabik/ | | __--^^^--__garabik melkordnpfmphunibask | --- Antivirus alert: file signature infected by signature virus Hi! I'm a signature virus! Copy me into your signature file to help me spread! -- Linux-UTF8: i18n of Linux on all levels Archive: http://mailnllinuxorg/linux-utf8/
Re: SI/SO G0/G1 in linux console
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 keysecho -e orders SI=G0=^O [Ctrl]+[o] \\033o \\x1bo \\x0e \\016 SO=G1=^N [Ctrl]+[n] \\033n \\x1bn \\x0f \\017 resultsnegative 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/
Re: NFS4 requires UTF-8
Followup to: [EMAIL PROTECTED] By author:Glenn Maynard [EMAIL PROTECTED] In newsgroup: linux.utf8 If a filename is a BOM followed by hello, how can I enter it? \ufeffhello -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt[EMAIL PROTECTED] -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
