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 <[email protected]> 写道： > > 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@gemfield-ThinkPad-Edge:~$ ls -ls >>>> 4 -rw-rw-r-- 1 gemfield gemfield 9 9 18 23:12 test >>>> gemfield@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.
