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

[Gemfield]

Yes, it is exactly same as bug#17838. Is -lsh  makes me have a misunderstanding 
that this file has a size of 4.0K blocks (4000*1024B)
.
Thanks.

发自Gemfield 的 iPhone

> 在 2014年9月19日，上午8:41，Pádraig Brady <address@hidden> 写道：
> 
> 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.