From owner-freebsd-hackers Mon Oct 16 14:16:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21638 for hackers-outgoing; Mon, 16 Oct 1995 14:16:15 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA21624 for ; Mon, 16 Oct 1995 14:15:59 -0700 Received: by sequent.kiae.su id AA00648 (5.65.kiae-2 ); Tue, 17 Oct 1995 01:15:07 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 17 Oct 95 01:15:07 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id AAA00617; Tue, 17 Jan 1995 00:10:14 +0300 To: joerg_wunsch@uriah.heep.sax.de, Terry Lambert Cc: hackers@freefall.freebsd.org, kaleb@x.org References: <199510162034.NAA25305@phaeton.artisoft.com> In-Reply-To: <199510162034.NAA25305@phaeton.artisoft.com>; from Terry Lambert at Mon, 16 Oct 1995 13:34:10 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 17 Jan 1995 00:10:13 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Lines: 61 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2524 Sender: owner-hackers@FreeBSD.org Precedence: bulk In message <199510162034.NAA25305@phaeton.artisoft.com> Terry Lambert writes: >> As Kaleb S. KEITHLEY wrote: >> > >> > As near as I can tell the SVR4 ls doesn't change its locale, yet still >> > manages to do the right thing, probably because for most SVR4-en the C >> > locale is full ISO8859-1. This leads me to believe that FreeBSD's ls >> > probably doesn't need to change its locale either if the default chartype >> > table is fully populated. >> >> So SVR4 would still break on koi8-r, for example. Either make it >> right, or let it be. >But not on 8859-x. For Coptic alphabets, that's 8859-9. SVR4/Kaleb solution breaks any charset which != 8859-1. >The problem with KOI-8 is that KOI-8 is a defacto standard, and is not >accepted by international standards bodies. Mostly because the most It accepted by IANA, see RFC 1700. >popular BBS software in the area picked it up instead of 8859-9. BSD software in the area uses CP866. >The problem is not in the blank areas of the locale. Why you even decide that problem is in the blank area? >In point of fact, the ANSI standards for terminal control sequences >after ANSI 3.64 leave the codes in columns 0x80 and 0x90 to be used >to represent 8 bit command sequence introducers, which are the same >as an escape character followed by a character in columns 0x20 or 0x30. >Because of this, KOI-8 as a character set is not compatible with post >3.64 ANSI terminal control sequence standardization. When KOI8-R code table was designed, it was keeped in mind, so 0x80 range cotains less used chars which can be safely ommited. >It is not unreasonable, then, for the code to function correctly in >the 8-bit case for ISO 8859-x but not function correctly without an >environment or (more preferrably) code change in the application for >KOI-8. Even 8859-2 becomes broken when C locale becomes 8859-1. Read full discussion before answering. >Really, they should be using the 8859 character set instead of KOI-8, >but there is understood to be a large historical investment in the >non-standard KOI-8 representation (unfortunately). 8859-5 us deadborn. Nobody use it currently. It was designed by foreigners for russians, such attempts are always deadborn. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849