linux-kernel - Re: UTF-8 and Alt key in the console

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.1.10.0803290055270.18418@fbirervta.pbzchgretzou.qr>
Date:	Sat, 29 Mar 2008 01:07:34 +0100 (CET)
From:	Jan Engelhardt <jengelh@...putergmbh.de>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	"John T." <j.thomast@...oo.com>, linux-kernel@...r.kernel.org
Subject: Re: UTF-8 and Alt key in the console

On Saturday 2008-03-29 00:26, H. Peter Anvin wrote:
>>
>>  About the ESC key, I thought, would it suffice to replace its
>>  current output of ^[ with ^[^[?
>
> It would be better to assign a CSI (ESC [) code to it, like other function 
> keys.  Unfortunately, the terminal everyone tries to emulate (Linux does so 
> quite poorly due to its broken implementation of ISO 2022, but that's less of 
> an issue with UTF-8), VT 220, had ESC on the F11 key, so the CSI 2 3 ~ 
> sequence it uses we use for the F11 key. Doesn't mean we can't assign another 
> one.

Even so, the linux term is the least broken one of all. I often had
issues with remote login programs (largely Windows ones) that had a
different idea of VTxxx whenever you wished not to have it. Despite
TERM being vt100 and the local encoding being vt100 too, actual
escape sequences were different from what programs in the shell
expected. On one occassion, F keys worked, but the Ins/Home does not,
in another it was reversed, etc. As soon as I learnt of putty a
few years ago I was happy to have all the mess that windows ssh
programs cause solved because it implemented the "linux" term type
and that just seemed to work out-of-the-box. So it does not seem
as broken to me as VTxxx.

> One would also like to distinguish, say, Backspace from Ctrl-H.  This is 
> trickier, because the termios settings don't permit compound keys.  The most 
> obvious way to deal with that is an escape code for Ctrl-H, but that has the 
> risk of breaking a lot of other things.

Like what? I know that ^H is abused for screen effects.. not much
you can do about it, but it is not that important anyway.

As for ^H, all that I think is needed is the generation of an
appropriate escape code for Ctrl-H and Backspace at the terminal
emulator level (read: a pure xterm thing what key gets translated
into what escape code), while the read side then interprets
"ESC CTRLH", "ESC BKSP" and the traditional "^H".

And while we are at it, I'd suggest a whole new set of escape
codes, the current sequences are particularly... bad for
stream synchronization. Right now one has to parse strings for
end-of-escape.. which is awkward. I'd just be able to
strchr(s, '^]') for example and know when the escape code
ends. (Compat should of course be honored where necessary.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/