Re: Badly formatted 'ls -l'

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> Thanks for your bug report.  That patch uncovers a few more problems
> in 'ls' with column widths (including some potential buffer overruns,

Please let us know if this is of more than theoretical interest.
If it's the one I'm thinking of, there was so much slack in the other
terms contributing to that buffer's length that one would be very
hard-pressed to contrive circumstances to provoke an actual overrun.

> sigh).  Rather than fix the problems piecemeal, how about if we adjust
> 'ls' so that it adjusts all the column widths to fit the data, not
> just the file sizes?  Here's a proposed patch, relative to CVS
> coreutils.
>
> 2003-12-03  Paul Eggert  <address@hidden>
>
>       * NEWS: ls -l (and similar options) now adjust all columns to
>       fit the data.  Generalized from a suggestion by Leah Q for file sizes.
>       * doc/coreutils.texi (What information is listed, chroot
>       invocation): Adjust example 'ls' output to match new behavior
>       with narrower output columns.
>       (The cut command): Remove example that cut the output of
>       'ls -l'.  The output was incorrect even with the old 'ls',
>       and the whole idea of using 'cut' on 'ls -l' output is bogus
>       anyway.

Thank you for the nice patch!
I've applied it with one minor consistency tweak:

I replaced these lines
  dired_pos += width;
  dired_pos++;
with this one
  dired_pos += width + 1;