GNU bug report logs - #10016
ls -lk is wrong

Previous Next

Full log

Message #23 received at 10016 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eric Blake <eblake <at> redhat.com>, Alan Curry <pacman-cu <at> kosh.dhis.org>,
	10016 <at> debbugs.gnu.org
Subject: Re: 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.