[Top][All Lists]
[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.
- bug#10016: ls -lk is wrong, Alan Curry, 2011/11/10
- bug#10016: ls -lk is wrong, Eric Blake, 2011/11/10
- bug#10016: ls -lk is wrong, Eric Blake, 2011/11/11
- bug#10016: ls -lk is wrong, Jim Meyering, 2011/11/11
- bug#10016: ls -lk is wrong, Paul Eggert, 2011/11/11
- bug#10016: ls -lk is wrong, Eric Blake, 2011/11/11
- bug#10016: ls -lk is wrong, Paul Eggert, 2011/11/11
- bug#10016: ls -lk is wrong, Jim Meyering, 2011/11/11
- bug#10016: ls -lk is wrong, Paul Eggert, 2011/11/12
- bug#9939: bug#10016: ls -lk is wrong, Jim Meyering, 2011/11/12
- bug#10016: ls -lk is wrong, Pádraig Brady, 2011/11/11