From owner-freebsd-hackers Sun Oct 15 10:48:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA04568 for hackers-outgoing; Sun, 15 Oct 1995 10:48:51 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA04563 for ; Sun, 15 Oct 1995 10:48:49 -0700 Received: from exalt.x.org by expo.x.org id AA10230; Sun, 15 Oct 95 13:48:00 -0400 Received: from localhost by exalt.x.org id NAA04827; Sun, 15 Oct 1995 13:47:59 -0400 Message-Id: <199510151747.NAA04827@exalt.x.org> To: hackers@freefall.FreeBSD.org Cc: ache@astral.msk.su Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP In-Reply-To: Your message of Sun, 15 Oct 1995 17:25:56 EST. <199510151625.RAA21043@uriah.heep.sax.de> Organization: X Consortium Date: Sun, 15 Oct 1995 13:47:59 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk Andrey Chernov said: >>just fixing ls isn't enough. The default table of character types in >>libc/locale/table.c isn't populated well enought to handle the whole >>ISO8859-1 character set. The following patch fixes ls, libc, and also >Default code table is ASCII and _not_ ISO8859-1, so it not needed to be >populated. Default code table is strict 7bit. No, it doesn't need to be, but is there a reason it can't do the right thing anyway? The table is defined as having 256 elements, so populating it with something useful isn't going to hurt anything. >>fixes some bugs in mklocale's lt_LN LC_CTYPE template. >BLANK fixes are incorrect, see isblank(3). Then the man page is wrong. The interpretation of blank on e.g. SVR4 is that *only* '0x20' is a "blank". On at least one SVR4 system I have here this is documented as specified by ISO8859-1. Compatibility is a good thing. I think you should be compatible. >XDIGIT fixes are right but ASCII locale used >for digits and xdigits in any cases. I'm not sure what this means. >Other fixes which includes some additional big/lower letters probably >can go, I need to check 8859-1 description first. You can check if you want. :-) >BTW, xterm is known to dump core when any of 8bit locales set, >f.e. ISO8859-1 or KOI8-R. color_xterm or mxterm works right. >Can you track this bug, please? What bug would this be? I'm not having any trouble at all running xterm in ISO8859-1 locales on FreeBSD 2.1.0-950922-SNAP (and I wouldn't have the first idea what to do in the KOI8-R locale :-)). You aren't by any chance using XFree86's xterm are you? If so report the problem to them. -- Kaleb KEITHLEY X Consortium