lkml.org 
[lkml]   [1997]   [Feb]   [15]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromAlexios Chouchoulas <>
SubjectUTF, console.c and ASCII 155
DateSun, 16 Feb 1997 03:44:12 +0200 (EET)
  Greetings.

  This is a query about relatively recent kernels. My sincere apologies if
this is a FAQ or it deserves instant flaming to hell and back. :-/

  Could someone please explain the rationale behind hardwiring ASCII 128+27
to be equivalent to ASCII 27 (ESC) in drivers/char/console.c? I know it's
the standard thing to do, but why can't it be turned off?

  Let me explain. Around line 1446 of drivers/char/console.c, we have

                ok = tc && (c >= 32 ||
                            (!utf && !(((disp_ctrl ? CTRL_ALWAYS
                                         : CTRL_ACTION) >> c) & 1)))
                        && (c != 127 || disp_ctrl)
                        && (c != 128+27);
  This determines if a character is printable or has to be interpreted as
some sort of action. Out of all characters in the 8-bit ASCII table, only
character 128+27 is treated specially: the glyphs at ALL other positions can
be printed, even the one for 27 (ESC). Why not the one for 128+27?

  The reasoning behind this question is that one particular national
language encoding (Greek code page 737, gradually being phased out by
ISO-8859-7 but still used by companies and a lot of BBSs alike) loses quite
an important glyph (lower-case delta) because of this.

  There seems to be no other way for this to work besides a kernel patch and
the whole point is that a lot of the people I support don't want to do this.


  Thanks,
Alexios

--------------------------- ,o88,o888o,,o888o. -------------------------------
Alexios Chouchoulas          '88    ,88'   ,88'     alexios@vennea.demon.co.uk
The Unpronouncable One      ,o88oooo88ooooo88oo,              axc@dcs.ed.ac.uk
\
 
 \ /
  Last update: 2005-03-22 13:38    [from the cache]
©2003-2008