Date: Sun, 15 Oct 1995 21:00:27 EST From: "Kaleb S. KEITHLEY" <kaleb@x.org> To: ache@astral.msk.su Cc: hackers@freefall.FreeBSD.org Subject: Re: A couple problems in FreeBSD 2.1.0-950922-SNAP Message-ID: <199510160100.VAA06828@exalt.x.org> In-Reply-To: Your message of Mon, 16 Oct 1995 02:25:29 EST. <YlfXPWmmJ1@ache.dialup.demos.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <199510151747.NAA04827@exalt.x.org> Kaleb S. KEITHLEY > writes: > > >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. > > Historycally ctype(>127) returns 0 in many systems that I see, Every day that goes by there are fewer and fewer people using those systems. Just because the U.S.-centric computer industry used to have tunnel vision when it came to i18n doesn't mean that "modern" systems should perpetuate the same mistakes into the future, especially when there's no reason not to fix it. > If you want 8859-1, just use proper locale. A nice suggestion. Too bad it doesn't work. ANSI/POSIX1 say that a program does the equivalent of setlocale(LC_ALL, "C") on startup. Given that ls, and I gather everything else, disregard my LANG, LC_ALL, and LC_CTYPE environment variables, I'm left wondering how it is you think that using the "proper locale" will help. Are you assuming that I'm using the undocumented hack of setting the ENABLE_STARTUP_LOCALE environment variable? > >>>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. > > If SVR4 do it, it isn't enough reason to do it too. Since isblank() > isn't POSIX function, I prefer to see some standards and docs before > change current behaviour. If you know such docs, please point me. As I said, at least one system's docs claim it spec'd in ISO8859-1. I don't have an ISO8859-1 at hand, and I'm not even sure I have one at work, although I must, somewhere. > >>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. > > xterm dumps core on startup when LANG variable set to one of > existen locales expect "C". This bug present in SNAP you mention. As I said, I don't have any problem with xterm, and no, I'm not using the "C" locale. > Yes, I mean XFree86 xterm (I don't think they can be differ, > but I am not shure). I am sure. They are different, that's why I asked. -- Kaleb
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510160100.VAA06828>