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

Previous Next

Full log

View this message in rfc822 format

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: 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.

Previous Next

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