Messages in this thread | | | Subject | Re: Default character set of the Linux console | Date | 30 Dec 1997 10:52:30 +0300 | From | Boris Tobotras <> |
| |
>>>>> "Qrczak" == Qrczak writes:
Qrczak> #define terminfo terminfo and termcap
Qrczak> Yes, I use this method now. But I treat this as a temporary Qrczak> solution until terminfos distributed with new Linuxes are changed Qrczak> this way.
Yes. But still this is userland problem.
Qrczak> Now the situation is not clear and some programs could Qrczak> reset the terminal with terminfo sequence assuming that it will Qrczak> reset the map (officially it still should reset the map, yes?), and
No. Tty mapping hasn't standardized in UN*X, so any application relying on terminfo on changing mapping have to be declared broken.
Qrczak> other may use direct ESCc although it would be better to leave the Qrczak> custom map active.
Why will they do that?
Qrczak> Maybe there are very few cases where this can Qrczak> cause problems, but for me this needs some clarification. It seems Qrczak> to work now, at least for programs using terminfo (logout resets Qrczak> the map even after fixing terminfo).
Is it? Never checked, but it should be trivial to check, which terminfo capability does it use. There are several init strings in (#undef terminfo) terminfo, and I'm not sure how applications are supposed to use them. Just in case I'd add \e(K to all of them.
Qrczak> I would be happy enough if it becomes the "official" way for doing Qrczak> this - if I could say that the assumption that resetting with Qrczak> terminfo rs1 sequence will reset the map is obsolete, and if good
In fact, where exactly does this assumption came from? I never saw any definitions of it.
Qrczak> programs _had to_ use terminfo instead of direct ESCc (this is Qrczak> probably true now).
Yes.
Qrczak> Probably one source of these problems is that many console settings Qrczak> are write-only. Programs can't simply check them, set their own Qrczak> values, use them and restore the previous state at the end. If Qrczak> programs only _could_ restore various settings, maybe resetting the Qrczak> terminal would be less important - now there is greater chance that Qrczak> a program would leave bad settings, because it can't read the old Qrczak> ones. There is even no simply check if console is in Unicode mode, Qrczak> and programs in console-tools package do this by outputting three Qrczak> bytes and checking how much the cursor had moved! This is obvious
Horrible :)
Qrczak> that knowing the state of Unicode mode is often important. Maybe Qrczak> future terminals should allow reading of some settings?
Should be trivial to extend linux console code to do that, any takers? :)
-- Best regards, -- Boris.
| |