Subject: bug#10016: ls -lk is wrong

From: Eric Blake <[email-masked]>
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   [email-masked]    +1-801-349-2682
Libvirt virtualization library http://libvirt.org