Date: Fri, 21 Nov 2003 12:24:00 +1100 From: Christopher Vance <vance@aurema.com> To: Tim Robbins <tjr@freebsd.org> Cc: freebsd-i18n@freebsd.org Subject: Re: /bin/ls incorrectly displays names of files on UTF-8 locales Message-ID: <20031121012400.GG12532@aurema.com> In-Reply-To: <20031121011303.GB67377@wombat.robbins.dropbear.id.au> References: <003001c3af96$c2336850$6701320a@komi.mts.ru> <20031121011303.GB67377@wombat.robbins.dropbear.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 21, 2003 at 12:13:03PM +1100, Tim Robbins wrote: >ls is trying to avoid writing what it thinks are non-printable characters, >to avoid screwing up the terminal by writing control characters etc. >It doesn't understand multibyte characters, though, so the output is >incorrect. (It doesn't understand characters that take up more than >one column on the screen, either.) There's already a PR about this problem, >but I haven't found the time to fix it; it involves scanning the string >with mbtowc() and checking each character with iswprint(). > >The other programs work correctly because they do not check for non-printable >characters. What character set did Alex have his terminal (program) set to? If the terminal was set to a character set with highbit data, ls should just pump the data out and let the terminal (program) handle multibyte rendering. As you've said, column alignment indicates either a need for ls to know character count. Cursor addressing might solve part of the problem, but not all. -- Christopher Vance
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031121012400.GG12532>