[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.