/bin/ls incorrectly displays names of files on UTF-8 locales
vance at aurema.com
Thu Nov 20 17:24:08 PST 2003
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
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.
More information about the freebsd-i18n