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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10016 in the body.
You can then email your comments to 10016 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: bug-coreutils <at> gnu.org
Subject: ls -lk is wrong
Date: Thu, 10 Nov 2011 18:35:32 -0500 (GMT+5)

I mentioned this already in the bug#9939 thread, but nobody replied and it's
really a separate issue so here's an independent report.

This behavior:

$ ls -l /bin/ls
-rwxr-xr-x 1 root root 107124 Feb  8  2011 /bin/ls
$ ls -lk /bin/ls
-rwxr-xr-x 1 root root 105 Feb  8  2011 /bin/ls

is awful. -k should not have any effect on the ls -l field that reports
st_size. It is only supposed to possibly affect the reporting of st_blocks
by -s and the "total" line at the start of a full directory listing.

I won't make any claims about what --block-size should do, but -k comes from
BSD and it should act like BSD.

-- 
Alan Curry

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

From: Eric Blake <eblake <at> redhat.com>
To: Alan Curry <pacman-cu <at> kosh.dhis.org>
Cc: 10016 <at> debbugs.gnu.org
Subject: Re: bug#10016: ls -lk is wrong
Date: Thu, 10 Nov 2011 17:14:23 -0700

On 11/10/2011 04:35 PM, Alan Curry wrote:
> I mentioned this already in the bug#9939 thread, but nobody replied and it's
> really a separate issue so here's an independent report.
>
> This behavior:
>
> $ ls -l /bin/ls
> -rwxr-xr-x 1 root root 107124 Feb  8  2011 /bin/ls
> $ ls -lk /bin/ls
> -rwxr-xr-x 1 root root 105 Feb  8  2011 /bin/ls
>
> is awful. -k should not have any effect on the ls -l field that reports
> st_size. It is only supposed to possibly affect the reporting of st_blocks
> by -s and the "total" line at the start of a full directory listing.

I just re-read POSIX, and it looks like you are correct:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html

-k
    Set the block size for the -s option and the per-directory block 
count written for the -l, -n, -s, [XSI] [Option Start] -g, and -o 
[Option End] options (see the STDOUT section) to 1024 bytes.

POSIX has no mention of -k affecting the file size output, just the 
initial column for -s and the per-directory summary on "total" lines.

>
> I won't make any claims about what --block-size should do, but -k comes from
> BSD and it should act like BSD.

It's not so much what BSD says, but what POSIX specifies, that matters 
here - I think you've made a pretty clear case that coreutils has a bug.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

From: Jim Meyering <jim <at> meyering.net>
To: Eric Blake <eblake <at> redhat.com>
Cc: 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 17:20:11 +0100

Eric Blake wrote:
> On 11/10/2011 04:35 PM, Alan Curry wrote:
>> I mentioned this already in the bug#9939 thread, but nobody replied and it's
>> really a separate issue so here's an independent report.
>>
>> This behavior:
>>
>> $ ls -l /bin/ls
>> -rwxr-xr-x 1 root root 107124 Feb  8  2011 /bin/ls
>> $ ls -lk /bin/ls
>> -rwxr-xr-x 1 root root 105 Feb  8  2011 /bin/ls
>>
>> is awful. -k should not have any effect on the ls -l field that reports
>> st_size. It is only supposed to possibly affect the reporting of st_blocks
>> by -s and the "total" line at the start of a full directory listing.
>
> I just re-read POSIX, and it looks like you are correct:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html
>
> -k
>     Set the block size for the -s option and the per-directory block
> count written for the -l, -n, -s, [XSI] [Option Start] -g, and -o
> [Option End] options (see the STDOUT section) to 1024 bytes.
>
> POSIX has no mention of -k affecting the file size output, just the
> initial column for -s and the per-directory summary on "total" lines.

Thank you, Alan!

I reached the same conclusion.
It is a bug.

It was introduced 9 years ago, in coreutils-4.5.4,
probably by commit 106c3bf3:

       sprintf (p, "%8s ",
-              human_readable (size, hbuf, 1,
-                              output_block_size < 0 ? output_block_size : 1));
+              human_readable (size, hbuf, human_output_opts,
+                              1, file_output_block_size));


Per POSIX, this should print 1000000:

    $ truncate -s 1000000 k; set - $(env ls -ogk k); echo $3
    977

The following change fixes it and introduces no test failure,
so I'll write a test, NEWS, etc.

diff --git a/src/ls.c b/src/ls.c
index 0b8f512..41e9123 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -3030,9 +3030,7 @@ gobble_file (char const *name, enum filetype type, ino_t inode,
             {
               char buf[LONGEST_HUMAN_READABLE + 1];
               uintmax_t size = unsigned_file_size (f->stat.st_size);
-              int len = mbswidth (human_readable (size, buf, human_output_opts,
-                                                  1, file_output_block_size),
-                                  0);
+              int len = mbswidth (human_readable (size, buf, 0, 1, 1), 0);
               if (file_size_width < len)
                 file_size_width = len;
             }
@@ -3772,7 +3770,7 @@ print_long_format (const struct fileinfo *f)
         (! f->stat_ok
          ? "?"
          : human_readable (unsigned_file_size (f->stat.st_size),
-                           hbuf, human_output_opts, 1, file_output_block_size));
+                           hbuf, 0, 1, 1));
       int pad;
       for (pad = file_size_width - mbswidth (size, 0); 0 < pad; pad--)
         *p++ = ' ';

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

From: Jim Meyering <jim <at> meyering.net>
To: Eric Blake <eblake <at> redhat.com>
Cc: 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 19:30:58 +0100

Jim Meyering wrote:
> Eric Blake wrote:
>> On 11/10/2011 04:35 PM, Alan Curry wrote:
>>> I mentioned this already in the bug#9939 thread, but nobody replied and it's
>>> really a separate issue so here's an independent report.
>>>
>>> This behavior:
>>>
>>> $ ls -l /bin/ls
>>> -rwxr-xr-x 1 root root 107124 Feb  8  2011 /bin/ls
>>> $ ls -lk /bin/ls
>>> -rwxr-xr-x 1 root root 105 Feb  8  2011 /bin/ls
>>>
>>> is awful. -k should not have any effect on the ls -l field that reports
>>> st_size. It is only supposed to possibly affect the reporting of st_blocks
>>> by -s and the "total" line at the start of a full directory listing.
>>
>> I just re-read POSIX, and it looks like you are correct:
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html
>>
>> -k
>>     Set the block size for the -s option and the per-directory block
>> count written for the -l, -n, -s, [XSI] [Option Start] -g, and -o
>> [Option End] options (see the STDOUT section) to 1024 bytes.
>>
>> POSIX has no mention of -k affecting the file size output, just the
>> initial column for -s and the per-directory summary on "total" lines.
>
> Thank you, Alan!
>
> I reached the same conclusion.
> It is a bug.
>
> It was introduced 9 years ago, in coreutils-4.5.4,
> probably by commit 106c3bf3:
>
>        sprintf (p, "%8s ",
> -              human_readable (size, hbuf, 1,
> -                              output_block_size < 0 ? output_block_size : 1));
> +              human_readable (size, hbuf, human_output_opts,
> +                              1, file_output_block_size));
>
>
> Per POSIX, this should print 1000000:
>
>     $ truncate -s 1000000 k; set - $(env ls -ogk k); echo $3
>     977
>
> The following change fixes it and introduces no test failure,
> so I'll write a test, NEWS, etc.
>
> diff --git a/src/ls.c b/src/ls.c
> index 0b8f512..41e9123 100644
> --- a/src/ls.c
> +++ b/src/ls.c
> @@ -3030,9 +3030,7 @@ gobble_file (char const *name, enum filetype type, ino_t inode,
>              {
>                char buf[LONGEST_HUMAN_READABLE + 1];
>                uintmax_t size = unsigned_file_size (f->stat.st_size);
> -              int len = mbswidth (human_readable (size, buf, human_output_opts,
> -                                                  1, file_output_block_size),
> -                                  0);
> +              int len = mbswidth (human_readable (size, buf, 0, 1, 1), 0);

I don't like the idea of printing a byte count there when
--block-size=... takes effect.  Does anyone else have an opinion?

Regardless, -k's descriptions will have to be fixed, too.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
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 10:49:34 -0800

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?

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

From: Eric Blake <eblake <at> redhat.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 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 11:36:46 -0700

[Message part 1 (text/plain, inline)]

On 11/11/2011 11:30 AM, Jim Meyering wrote:
>> +++ b/src/ls.c
>> @@ -3030,9 +3030,7 @@ gobble_file (char const *name, enum filetype type, ino_t inode,
>>              {
>>                char buf[LONGEST_HUMAN_READABLE + 1];
>>                uintmax_t size = unsigned_file_size (f->stat.st_size);
>> -              int len = mbswidth (human_readable (size, buf, human_output_opts,
>> -                                                  1, file_output_block_size),
>> -                                  0);
>> +              int len = mbswidth (human_readable (size, buf, 0, 1, 1), 0);
> 
> I don't like the idea of printing a byte count there when
> --block-size=... takes effect.  Does anyone else have an opinion?

Are you proposing that --block-size keep the current behavior, and that
-k no longer be a synonym for --block-size=1k but instead becomes a new
long option?

Makes sense to me - POSIX didn't standardize -k until 2008, which was
long after coreutils had been implementing --block-size; I'm worried
that changing the behavior of --block-size may have negative effects,
whereas changing the behavior of -k to match POSIX is justifiable.

> 
> Regardless, -k's descriptions will have to be fixed, too.

Agreed.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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.

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

From: Jim Meyering <jim <at> meyering.net>
To: Eric Blake <eblake <at> redhat.com>
Cc: 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:48 +0100

Eric Blake wrote:

> On 11/11/2011 11:30 AM, Jim Meyering wrote:
>>> +++ b/src/ls.c
>>> @@ -3030,9 +3030,7 @@ gobble_file (char const *name, enum filetype type, ino_t inode,
>>>              {
>>>                char buf[LONGEST_HUMAN_READABLE + 1];
>>>                uintmax_t size = unsigned_file_size (f->stat.st_size);
>>> -              int len = mbswidth (human_readable (size, buf, human_output_opts,
>>> -                                                  1, file_output_block_size),
>>> -                                  0);
>>> +              int len = mbswidth (human_readable (size, buf, 0, 1, 1), 0);
>>
>> I don't like the idea of printing a byte count there when
>> --block-size=... takes effect.  Does anyone else have an opinion?
>
> Are you proposing that --block-size keep the current behavior, and that
> -k no longer be a synonym for --block-size=1k but instead becomes a new
> long option?

Precisely.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eric Blake <eblake <at> redhat.com>
Cc: 10016 <at> debbugs.gnu.org, Jim Meyering <jim <at> meyering.net>,
	Alan Curry <pacman-cu <at> kosh.dhis.org>
Subject: Re: bug#10016: ls -lk is wrong
Date: Fri, 11 Nov 2011 11:25:40 -0800

On 11/11/2011 10:36 AM, Eric Blake wrote:
> Are you proposing that --block-size keep the current behavior, and that
> -k no longer be a synonym for --block-size=1k but instead becomes a new
> long option?
>
> Makes sense to me

That sort of thing makes sense to me too.
I assume --block-size should silently override -k
if both options are specified (in either order)?
Does -k need a long-named option?

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

From: Eric Blake <eblake <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 10016 <at> debbugs.gnu.org, Jim Meyering <jim <at> meyering.net>,
	Alan Curry <pacman-cu <at> kosh.dhis.org>
Subject: Re: bug#10016: ls -lk is wrong
Date: Fri, 11 Nov 2011 13:27:01 -0700

[Message part 1 (text/plain, inline)]

On 11/11/2011 12:25 PM, Paul Eggert wrote:
> On 11/11/2011 10:36 AM, Eric Blake wrote:
>> Are you proposing that --block-size keep the current behavior, and that
>> -k no longer be a synonym for --block-size=1k but instead becomes a new
>> long option?
>>
>> Makes sense to me
> 
> That sort of thing makes sense to me too.
> I assume --block-size should silently override -k
> if both options are specified (in either order)?
> Does -k need a long-named option?

GNU Coding Standards request that all short options have a corresponding
long option; by breaking the tie between -k and --block-size, we are
breaking that convention unless we also add a new long option for the
new meaning of -k.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eric Blake <eblake <at> redhat.com>
Cc: 10016 <at> debbugs.gnu.org, Jim Meyering <jim <at> meyering.net>,
	Alan Curry <pacman-cu <at> kosh.dhis.org>
Subject: Re: bug#10016: ls -lk is wrong
Date: Fri, 11 Nov 2011 13:06:14 -0800

The long option shouldn't be --kilobyte, since ls -k means
1024 not 1000.  So I suppose it should be --kibibyte.

It's a little tricky, since -k means --block-size=1K
for df and du as well, and I assume this won't change,
since df -k and du -k conform to POSIX. (Surely there's
no need to add --kibibyte to du and df -- why should
we make df and du more confusing merely because
ls must be more confusing? :-).

So does the following sound plausible?

Add --kibibyte to 'ls', make it equivalent to -k, change
-k so that it conforms to POSIX, and have --block-size
override -k.  But leave df and du alone

Message #38 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 22:10:44 +0100

Paul Eggert wrote:
> The long option shouldn't be --kilobyte, since ls -k means
> 1024 not 1000.  So I suppose it should be --kibibyte.
>
> It's a little tricky, since -k means --block-size=1K
> for df and du as well, and I assume this won't change,
> since df -k and du -k conform to POSIX. (Surely there's
> no need to add --kibibyte to du and df -- why should
> we make df and du more confusing merely because
> ls must be more confusing? :-).
>
> So does the following sound plausible?
>
> Add --kibibyte to 'ls', make it equivalent to -k, change
> -k so that it conforms to POSIX, and have --block-size
> override -k.  But leave df and du alone

That sounds right.
Do you feel like writing the patch?

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

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: jim <at> meyering.net (Jim Meyering)
Cc: 10016 <at> debbugs.gnu.org
Subject: Re: bug#10016: ls -lk is wrong
Date: Fri, 11 Nov 2011 17:53:50 -0500 (GMT+5)

Jim Meyering writes:
> 
> 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.
> 

Wow, look what I stirred up.

If it's been like this for 9 years, it's been broken for 9 years. As I said
originally, BSD is the standard that matters here. It doesn't matter when or
even whether POSIX blessed the -k option.

Everywhere except GNU, this is simple. The size field of the ls -l output is
not defined in terms of blocks, so the block size setting doesn't affect it.

Numbers derived from st_blocks are reported in units of blocks, and others
aren't.

If you're going to define --block-size to have this effect, then you really
need to document it as being an option that does 2 separate things:
  1. sets the size of a block
  2. alters the definition of the -l format

-- 
Alan Curry

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 10016 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>,
	Alan Curry <pacman-cu <at> kosh.dhis.org>, Jim Meyering <jim <at> meyering.net>
Subject: Re: bug#10016: ls -lk is wrong
Date: Sat, 12 Nov 2011 00:56:29 +0000

On 11/11/2011 09:06 PM, Paul Eggert wrote:
> The long option shouldn't be --kilobyte, since ls -k means
> 1024 not 1000.  So I suppose it should be --kibibyte.
> 
> It's a little tricky, since -k means --block-size=1K
> for df and du as well, and I assume this won't change,
> since df -k and du -k conform to POSIX. (Surely there's
> no need to add --kibibyte to du and df -- why should
> we make df and du more confusing merely because
> ls must be more confusing? :-).
> 
> So does the following sound plausible?
> 
> Add --kibibyte to 'ls', make it equivalent to -k, change
> -k so that it conforms to POSIX, and have --block-size
> override -k.  But leave df and du alone

I'm reluctant to add a new option which no one will really use.
But I concur, given the hits from:

http://codesearch.google.com/#search/&q=ls\%20.*--block%20lang:^shell$&p=1&type=cs

-k really isn't used in that context, and replacing --block with -k
in the above query returns no hits.

cheers,
Pádraig.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: 9939 <at> debbugs.gnu.org, 10016-done <at> debbugs.gnu.org,
	Eric Blake <eblake <at> redhat.com>, Alan Curry <pacman-cu <at> kosh.dhis.org>
Subject: Re: bug#10016: ls -lk is wrong
Date: Fri, 11 Nov 2011 23:40:36 -0800

On 11/11/11 13:10, Jim Meyering wrote:
> Do you feel like writing the patch?

Sure.  I wrote and pushed the following.
The test case isn't elegant, but at least it catches the bug.

ls: -k no longer affects -l's file sizes
This fixes an incompatibility with POSIX 2008 and with BSD.
Problem reported by Abdallah Clark (Bug#9939)
via Alan Curry (Bug#10016).
* NEWS: Document this.
* doc/coreutils.texi (General output formatting): Document the
new -k behavior, and --kibibytes.
* src/ls.c (file_human_output_opts): New static var.
(long_options, usage): Add --kibibytes.
(decode_switches, gobble_file, print_long_format):
Implement the new -k behavior.
* tests/ls/block-size: New file.
* tests/Makefile.am (TESTS): Add it.
diff --git a/NEWS b/NEWS
index 081989d..1b0f2f5 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,13 @@ GNU coreutils NEWS                                    -*- outline -*-

 ** Bug fixes

+  ls's -k option no longer affects how ls -l outputs file sizes.
+  It now affects only the per-directory block counts written by -l,
+  and the sizes written by -s.  This is for compatibility with BSD
+  and with POSIX 2008.  Because -k is no longer equivalent to
+  --block-size=1KiB, a new long option --kibibyte stands for -k.
+  [bug introduced in coreutils-4.5.4]
+
   rm -rf DIR would fail with "Device or resource busy" on Cygwin with NWFS
   and NcFsd file systems.  This did not affect Unix/Linux-based kernels.
   [bug introduced in coreutils-8.0, when rm began using fts]
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 2c33fe8..4531440 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7127,10 +7127,19 @@ Append @samp{*} for executable regular files, otherwise behave as for
 @end table

 @item -k
+@itemx --kibibytes
 @opindex -k
-Print file sizes in 1024-byte blocks, overriding the default block
-size (@pxref{Block size}).
-This option is equivalent to @option{--block-size=1K}.
+@opindex --kibibytes
+Set the default block size to its normal value of 1024 bytes,
+overriding any contrary specification in environment variables
+(@pxref{Block size}).  This option is in turn overridden by the
+@option{--block-size}, @option{-h} or @option{--human-readable}, and
+@option{--si} options.
+
+The @option{-k} or @option{--kibibytes} option affects the
+per-directory block count written by the @option{-l} and similar
+options, and the size written by the @option{-s} or @option{--size}
+option.  It does not affect the file size written by @option{-l}.

 @item -m
 @itemx --format=commas
diff --git a/src/ls.c b/src/ls.c
index 1b0c250..b8a09b3 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -479,13 +479,14 @@ static bool numeric_ids;

 static bool print_block_size;

-/* Human-readable options for output.  */
+/* Human-readable options for output, when printing block counts.  */
 static int human_output_opts;

-/* The units to use when printing sizes other than file sizes.  */
+/* The units to use when printing block counts.  */
 static uintmax_t output_block_size;

 /* Likewise, but for file sizes.  */
+static int file_human_output_opts;
 static uintmax_t file_output_block_size = 1;

 /* Follow the output with a special string.  Using this format,
@@ -809,6 +810,7 @@ static struct option const long_options[] =
    GROUP_DIRECTORIES_FIRST_OPTION},
   {"human-readable", no_argument, NULL, 'h'},
   {"inode", no_argument, NULL, 'i'},
+  {"kibibytes", no_argument, NULL, 'k'},
   {"numeric-uid-gid", no_argument, NULL, 'n'},
   {"no-group", no_argument, NULL, 'G'},
   {"hide-control-chars", no_argument, NULL, 'q'},
@@ -1512,8 +1514,8 @@ decode_switches (int argc, char **argv)
 {
   char *time_style_option = NULL;

-  /* Record whether there is an option specifying sort type.  */
   bool sort_type_specified = false;
+  bool kibibytes_specified = false;

   qmark_funny_chars = false;

@@ -1582,14 +1584,6 @@ decode_switches (int argc, char **argv)
       }
   }

-  {
-    char const *ls_block_size = getenv ("LS_BLOCK_SIZE");
-    human_options (ls_block_size,
-                   &human_output_opts, &output_block_size);
-    if (ls_block_size || getenv ("BLOCK_SIZE"))
-      file_output_block_size = output_block_size;
-  }
-
   line_length = 80;
   {
     char const *p = getenv ("COLUMNS");
@@ -1689,7 +1683,8 @@ decode_switches (int argc, char **argv)
           break;

         case 'h':
-          human_output_opts = human_autoscale | human_SI | human_base_1024;
+          file_human_output_opts = human_output_opts =
+            human_autoscale | human_SI | human_base_1024;
           file_output_block_size = output_block_size = 1;
           break;

@@ -1698,8 +1693,7 @@ decode_switches (int argc, char **argv)
           break;

         case 'k':
-          human_output_opts = 0;
-          file_output_block_size = output_block_size = 1024;
+          kibibytes_specified = true;
           break;

         case 'l':
@@ -1937,12 +1931,14 @@ decode_switches (int argc, char **argv)
                                                  &output_block_size);
             if (e != LONGINT_OK)
               xstrtol_fatal (e, oi, 0, long_options, optarg);
+            file_human_output_opts = human_output_opts;
             file_output_block_size = output_block_size;
           }
           break;

         case SI_OPTION:
-          human_output_opts = human_autoscale | human_SI;
+          file_human_output_opts = human_output_opts =
+            human_autoscale | human_SI;
           file_output_block_size = output_block_size = 1;
           break;

@@ -1959,6 +1955,23 @@ decode_switches (int argc, char **argv)
         }
     }

+  if (! output_block_size)
+    {
+      char const *ls_block_size = getenv ("LS_BLOCK_SIZE");
+      human_options (ls_block_size,
+                     &human_output_opts, &output_block_size);
+      if (ls_block_size || getenv ("BLOCK_SIZE"))
+        {
+          file_human_output_opts = human_output_opts;
+          file_output_block_size = output_block_size;
+        }
+      if (kibibytes_specified)
+        {
+          human_output_opts = 0;
+          output_block_size = 1024;
+        }
+    }
+
   max_idx = MAX (1, line_length / MIN_COLUMN_WIDTH);

   filename_quoting_options = clone_quoting_options (NULL);
@@ -3025,7 +3038,8 @@ gobble_file (char const *name, enum filetype type, ino_t inode,
             {
               char buf[LONGEST_HUMAN_READABLE + 1];
               uintmax_t size = unsigned_file_size (f->stat.st_size);
-              int len = mbswidth (human_readable (size, buf, human_output_opts,
+              int len = mbswidth (human_readable (size, buf,
+                                                  file_human_output_opts,
                                                   1, file_output_block_size),
                                   0);
               if (file_size_width < len)
@@ -3767,7 +3781,8 @@ print_long_format (const struct fileinfo *f)
         (! f->stat_ok
          ? "?"
          : human_readable (unsigned_file_size (f->stat.st_size),
-                           hbuf, human_output_opts, 1, file_output_block_size));
+                           hbuf, file_human_output_opts, 1,
+                           file_output_block_size));
       int pad;
       for (pad = file_size_width - mbswidth (size, 0); 0 < pad; pad--)
         *p++ = ' ';
@@ -4672,7 +4687,7 @@ Mandatory arguments to long options are mandatory for short options too.\n\
   -i, --inode                print the index number of each file\n\
   -I, --ignore=PATTERN       do not list implied entries matching shell PATTERN\
 \n\
-  -k                         like --block-size=1K\n\
+  -k, --kibibytes            use 1024-byte blocks\n\
 "), stdout);
       fputs (_("\
   -l                         use a long listing format\n\
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 5021c18..64366a4 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -415,6 +415,7 @@ TESTS =						\
   ln/slash-decorated-nonexistent-dest		\
   ln/target-1					\
   ls/abmon-align				\
+  ls/block-size					\
   ls/color-clear-to-eol				\
   ls/color-dtype-dir				\
   ls/color-norm					\
diff --git a/tests/ls/block-size b/tests/ls/block-size
new file mode 100644
index 0000000..16ede04
--- /dev/null
+++ b/tests/ls/block-size
@@ -0,0 +1,173 @@
+#!/bin/sh
+# Exercise ls --block-size and related options.
+
+# Copyright (C) 2011 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+. "${srcdir=.}/init.sh"; path_prepend_ ../src
+print_ver_ ls
+
+TZ=UTC0
+export TZ
+
+mkdir sub
+cd sub
+
+for size in 1024 4096 262144; do
+  echo foo | dd conv=sync bs=$size >file$size || fail=1
+done
+touch -d '2001-01-01 00:00' file* || fail=1
+
+size_etc='s/[^ ]* *[^ ]* *[^ ]* *[^ ]* *//'
+
+ls -l * | sed "$size_etc" >../out || fail=1
+POSIXLY_CORRECT=1 ls -l * | sed "$size_etc" >>../out || fail=1
+POSIXLY_CORRECT=1 ls -k -l * | sed "$size_etc" >>../out || fail=1
+
+for var in BLOCKSIZE BLOCK_SIZE LS_BLOCK_SIZE; do
+  for blocksize in 1 512 1K 1KiB; do
+    (eval $var=$blocksize && export $var &&
+     ls -l * &&
+     ls -l -k * &&
+     ls -l -k --block-size=$blocksize *
+    ) | sed "$size_etc" >>../out || fail=1
+  done
+done
+
+cd ..
+
+cat >exp <<'EOF'
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+2 Jan  1  2001 file1024
+512 Jan  1  2001 file262144
+8 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+2 Jan  1  2001 file1024
+512 Jan  1  2001 file262144
+8 Jan  1  2001 file4096
+2 Jan  1  2001 file1024
+512 Jan  1  2001 file262144
+8 Jan  1  2001 file4096
+2 Jan  1  2001 file1024
+512 Jan  1  2001 file262144
+8 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+1024 Jan  1  2001 file1024
+262144 Jan  1  2001 file262144
+4096 Jan  1  2001 file4096
+2 Jan  1  2001 file1024
+512 Jan  1  2001 file262144
+8 Jan  1  2001 file4096
+2 Jan  1  2001 file1024
+512 Jan  1  2001 file262144
+8 Jan  1  2001 file4096
+2 Jan  1  2001 file1024
+512 Jan  1  2001 file262144
+8 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+1 Jan  1  2001 file1024
+256 Jan  1  2001 file262144
+4 Jan  1  2001 file4096
+EOF
+
+compare out exp || fail=1
+
+Exit $fail

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

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9939 <at> debbugs.gnu.org, 10016-done <at> debbugs.gnu.org,
	Eric Blake <eblake <at> redhat.com>, Alan Curry <pacman-cu <at> kosh.dhis.org>
Subject: Re: bug#10016: ls -lk is wrong
Date: Sat, 12 Nov 2011 10:46:45 +0100

Paul Eggert wrote:
> On 11/11/11 13:10, Jim Meyering wrote:
>> Do you feel like writing the patch?
>
> Sure.  I wrote and pushed the following.
> The test case isn't elegant, but at least it catches the bug.

That was quick.  Thanks!

Previous Next

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