bug-coreutils
[Top][All Lists]
Advanced

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

bug#10016: ls -lk is wrong


From: Jim Meyering
Subject: bug#10016: ls -lk is wrong
Date: Fri, 11 Nov 2011 20:24:00 +0100

Paul Eggert wrote:

> On 11/11/2011 10:30 AM, Jim Meyering wrote:
>> I don't like the idea of printing a byte count there when
>> --block-size=... takes effect.  Does anyone else have an opinion?
> Sorry, I've lost context.  Are you talking about
> the output of "ls -ls --block-size=1"?
> Currently it starts with something like
> "total 8642560", and then each line looks something
> like this:
>
> 40960 -rwxr-xr-x 1 root root 38484 2011-02-23 05:22 foo
>
> where the "8642560", the "40960", and the "38484"
> are all byte counts.  Which of these three numbers are
> you thinking should not be a byte count when the block
> size is 1?  And how should the --si and -h options affect
> that number's display?

I'm talking only about the st.st_size number, your 38484 above,
when using -k with a long-listing option like -l, -o or -g.
POSIX requires a byte-count (as you get with --block-size=1),
but we print a block count.

I'm thinking of making -k comply, but letting any block-size
specification (via --block-size= or an envvar) override that
to give the behavior we've seen for the last 9 years.





reply via email to

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