bug-coreutils
[Top][All Lists]
Advanced

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

bug#18503: [bug-report] the output of ls -lsh


From: Pádraig Brady
Subject: bug#18503: [bug-report] the output of ls -lsh
Date: Fri, 19 Sep 2014 01:41:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

unmerge 17553 18503
forcemerge 17838 18503
stop

On 09/19/2014 01:05 AM, Pádraig Brady wrote:
> unarchive 17553
> forcemerge 17553 18503
> stop
> 
> On 09/19/2014 12:17 AM, Linda A. Walsh wrote:
>> gemfield wrote:
>>>    Hi,
>>>    I am running ls -lsh on kubuntu 14.04, here is the output:
>>>    address@hidden:~$ ls -ls
>>>    4 -rw-rw-r-- 1 gemfield gemfield    9  9 18 23:12 test
>>>    address@hidden:~$ ls -lsh
>>>    4.0K -rw-rw-r-- 1 gemfield gemfield    9  9 18 23:12 test
>>>    the "4" colored by green means 4 blocks, so why becomes 4.0K blocks
>>>      when add -h option to ls -ls?
>>>   
>> 4  * 1K blocks = 4.0K blocks.
>                        ^^^^^^ -> bytes
> 
> I think the ambiguity is that there is no unit output.
> With the human output options, bytes are the implicit unit rather than blocks.
> 
> The documentation on the human output options does mention that
> bytes are being specified rather than blocks:
> http://www.gnu.org/software/coreutils/manual/coreutils.html#Block-size
> 
> Ideally you're right that we should be outputting 4KB
> or more accurately 4KiB, though due to backward compat concerns
> we use the less verbose but more ambiguous format.
> 
> For more explicit conversions you can run ls through the
> numfmt utility as described at http://bugs.gnu.org/17553
> In fact the issues are much the same as with that bug
> so I'll merge them.

Actually http://bugs.gnu.org/17838 is essentially the same issue.
The resolution there was to mention how -h impacts -s in the man page,
and that improvement was released in coreutils 8.23

thanks,
Pádraig.





reply via email to

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