Jan Engelhardt <jeng...@medozas.de> wrote:
> On Tuesday 2008-12-30 21:47, Jim Meyering wrote:
>>
>>Thanks for the follow-up.
>>I've just tried to reproduce the problem using the latest
>>version of ls, invoked from a linux vt, then xterm, aterm and rxvt
>>windows. Each time, I did this in an empty directory:
>>
>> seq 100|xargs touch; touch z.foo
>> env LS_COLORS='*.foo=0;31;42' ls -l --color
>>
>>All I see on the last line is a red "z.foo" on a green background,
>>and then the usual prompt.
>
> You have to use a long filename (not just z.foo) that wraps in the
> terminal. See the video at
> http://jengelh.medozas.de/files/coreutils7ls.ogv for details.
> Version used was v7.0-114-g921feef.
>
> Standard ./configure and (slightly abridged) make, as shown.
I see now.
It doesn't even need to be last, if you run the ls
command from the "bottom" of the window:
seq 200
mkdir -m 502 $(perl -e 'print "a"x84')
env ls --color -d aaa*
rmdir aaa*
That gives me a line of blue-on-green 'a's followed by
an all-green line with 3 blue 'a's.
With your patch, the second line has only 3 positions
(the 'a's) with green background.
While the patch produces obviously better output in this case,
the resulting colorized ls output is always bigger by two bytes
per colored file name. (it also hard-codes the existing lc+no+rc
escapes, which it'd be better not to do, since they're user-settable)
Would one of you care to adjust the patch so the additional escape
sequence is emitted only when needed (i.e., when ls thinks a colored name
has wrapped)? Note that even that will sometimes print the extra escape
sequence unnecessarily, e.g., when we're printing file-type suffixes,
but that's ok.
While the adjusted patch will be significantly larger than
the original one-liner, the problem it fixes is unusual enough
that we should try to minimize the impact on unaffected uses.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
