bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Alignment bug in ls with UTF-8 filenames under Mac OS X


From: Jim Meyering
Subject: Re: Alignment bug in ls with UTF-8 filenames under Mac OS X
Date: Thu, 18 Jan 2007 17:01:10 +0100

Bruno Haible <address@hidden> wrote:
> Vincent Lefevre wrote:
...
>> > I see that the first call to wcwidth() gives: wcwidth(0x0301) = 1.
>> > U+0301 is COMBINING ACUTE ACCENT. So here is the problem: MacOS'
>> > wcwidth is buggy for combining characters like accents.
>>
>> OK. Can't autoconf detect that and use another implementation?
>
> Yes. We can do that in gnulib. I'll work on this issue in the next few weeks.
> Please remind us (on the bug-gnulib mailing list) in 1 or 2 months.

Thanks for volunteering to do that.

> And, as we have seen, the other issue is that Apple Terminal has problems
> estimating the width of tabs when there are non-ASCII characters. Since
> you can start an telnet/ssh session from MacOS X to any platform (Linux,
> Solaris, etc.), the fix needs to be platform independent. Here is such a fix:
>
> 2007-01-18  Bruno Haible  <address@hidden>
>
>       Avoid problems with tabs after non-ASCII characters in some terminals.
>       * src/ls.c (nonascii_in_this_line): New variable.
>       (quote_name): Update nonascii_in_this_line.
>       (print_many_per_line, print_horizontal): Set nonascii_in_this_line to
>       false at the beginning of each line.
>       (indent): Use spaces for indentation when nonascii_in_this_line.

Thank you for working on this.
As I understand the goal, you'd like to make ls act differently
(outputting spaces, not TABs, for column alignment) on all systems
for each line containing a non-ASCII byte.  The proposed change in
behavior would serve solely to make it so columns line up better when
displaying on a buggy Apple Terminal.

That change would contradict the documentation of -T, but more
importantly, it would make the output significantly larger when there are
wide columns and many lines containing a non-ASCII byte, thus penalizing
all users in order to cater to a buggy terminal emulator.

I would rather simply have someone who cares about Apple Terminal
report the bug, and in the mean time, advise people to use "-T0"
(or set TABSIZE=0 in their environment) if they care about alignment
when using a buggy version of that particular terminal emulator.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]