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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18503 in the body.
You can then email your comments to 18503 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: gemfield <gemfield <at> civilnet.cn>
To: bug-coreutils <bug-coreutils <at> gnu.org>
Subject: [bug-report] the output of ls -lsh
Date: Thu, 18 Sep 2014 23:23:40 +0800 (GMT+08:00)

[Message part 1 (text/html, inline)]

[Message part 2 (text/plain, inline)]

Hi,
I am running ls -lsh on kubuntu 14.04, here is the output:

gemfield <at> gemfield-ThinkPad-Edge:~$ ls -ls
4 -rw-rw-r-- 1 gemfield gemfield    9  9 18 23:12 test

gemfield <at> gemfield-ThinkPad-Edge:~$ 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?

gemfield <at> gemfield-ThinkPad-Edge:~$ uname -a
Linux gemfield-ThinkPad-Edge 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:01 UTC 2014 i686 i686 i686 GNU/Linux
gemfield <at> gemfield-ThinkPad-Edge:~$ ls --version
ls (GNU coreutils) 8.21
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard M. Stallman and David MacKenzie.

Thanks.

Gemfield.

Message #8 received at 18503 <at> debbugs.gnu.org (full text, mbox):

From: "Linda A. Walsh" <coreutils <at> tlinx.org>
To: gemfield <gemfield <at> civilnet.cn>
Cc: 18503 <at> debbugs.gnu.org
Subject: Re: bug#18503: [bug-report] the output of ls -lsh
Date: Thu, 18 Sep 2014 16:17:40 -0700

gemfield wrote:
>    Hi,
>    I am running ls -lsh on kubuntu 14.04, here is the output:
>    gemfield <at> gemfield-ThinkPad-Edge:~$ ls -ls
>    4 -rw-rw-r-- 1 gemfield gemfield    9  9 18 23:12 test
>    gemfield <at> gemfield-ThinkPad-Edge:~$ 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.

-h has been an option of ls for many years.

blocks in "ls" are 1K in size.

What problem or bug are you reporting?

Seems to be working it ever has....(or I'm missing your point).

Message #11 received at 18503 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: "Linda A. Walsh" <coreutils <at> tlinx.org>
Cc: 18503 <at> debbugs.gnu.org, gemfield <gemfield <at> civilnet.cn>
Subject: Re: bug#18503: [bug-report] the output of ls -lsh
Date: Fri, 19 Sep 2014 01:05:38 +0100

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:
>>    gemfield <at> gemfield-ThinkPad-Edge:~$ ls -ls
>>    4 -rw-rw-r-- 1 gemfield gemfield    9  9 18 23:12 test
>>    gemfield <at> gemfield-ThinkPad-Edge:~$ 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.

thanks,
Pádraig.

Message #16 received at 18503 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: "Linda A. Walsh" <coreutils <at> tlinx.org>
Cc: 18503 <at> debbugs.gnu.org, gemfield <gemfield <at> civilnet.cn>
Subject: Re: bug#18503: [bug-report] the output of ls -lsh
Date: Fri, 19 Sep 2014 01:41:00 +0100

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:
>>>    gemfield <at> gemfield-ThinkPad-Edge:~$ ls -ls
>>>    4 -rw-rw-r-- 1 gemfield gemfield    9  9 18 23:12 test
>>>    gemfield <at> gemfield-ThinkPad-Edge:~$ 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.

Message #23 received at 18503 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 18503 <at> debbugs.gnu.org
Subject: Re: bug#18503: [bug-report] the output of ls -lsh
Date: Thu, 18 Sep 2014 22:02:20 -0700

> On 09/19/2014 12:17 AM, Linda A. Walsh wrote:
>> gemfield wrote:  
>> 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.

Those darn trees!  Can't see the forest because of...

Message #26 received at 18503 <at> debbugs.gnu.org (full text, mbox):

From: Gemfield <gemfield <at> civilnet.cn>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: "18503 <at> debbugs.gnu.org" <18503 <at> debbugs.gnu.org>,
 "Linda A. Walsh" <coreutils <at> tlinx.org>
Subject: Re: 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 <P <at> draigBrady.com> 写道：
> 
> 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:
>>>>   gemfield <at> gemfield-ThinkPad-Edge:~$ ls -ls
>>>>   4 -rw-rw-r-- 1 gemfield gemfield    9  9 18 23:12 test
>>>>   gemfield <at> gemfield-ThinkPad-Edge:~$ 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.