[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10016: ls -lk is wrong

From: Eric Blake
Subject: bug#10016: ls -lk is wrong
Date: Thu, 10 Nov 2011 17:14:23 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110928 Fedora/3.1.15-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.15

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:


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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]