[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18503: [bug-report] the output of ls -lsh
From: |
Gemfield |
Subject: |
bug#18503: [bug-report] the output of ls -lsh |
Date: |
Fri, 19 Sep 2014 22:39:13 +0800 |
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.