bug#9939: Problems with the SIZE description in man pages for <ls> and <du>

[abdallah clark]

Dear Paul,

I hope that you and your family are well. I'm doing fine and feeling
like I'm making better progress on a few levels lately. Also, I found
a set of simple examples for the tee command in a very old book that
were quite useful. I was reading it for shell programming and it's
index didn't even list "tee" at all, but they had four  pages using
it. Thank God for "serendipity!"

I was wondering if you received my very detailed account of the issues
I found with the <ls -l --block-size=SIZE> command. It's been about a
week since I sent it, so I wasn't sure what was happening.

I saved it as a text file also, so it would be easy to re-send it to
you if necessary.

I am very curious to see whether my understanding of the option is the
case, or if there really are errors/bugs in it.

I await your acknowledgement of that e-mail. Thanks again for your
consideration.

          All the best to you and yours,

                 Abdallah Clark




On Wed, Nov 2, 2011 at 11:01 AM, Paul Eggert <address@hidden> wrote:
> On 11/02/11 03:40, abdallah clark wrote:
>
>> the units are not
>> consistent with the ISO/SI units-- K and M are in units of 1000, not
>> 1024, because they are part of the metric system, not the binary
>> system.
>
> coreutils is supporting three notations here: SI-ish,
> IEC 60027-2 / ISO/IEC 80000-13:2008, and traditional Unix.
> So:
>
>  MB means 1000*1000 bytes.  This is like SI, except SI doesn't have "B".
>  MiB means 1024*1024 bytes.  This is IEC 60027-2 and ISO/IEC 80000-13:2008.
>  M means MiB.  This is traditional Unix.
>
> See <http://en.wikipedia.org/wiki/Binary_prefix> for more info.
> (coreutils cannot use plain SI, since SI doesn't specify
> an abbreviation for "byte".)
>
>> it is just too awkwardly
>> written to be understood on the first reading.
>
> Suggestions for improved wording are welcome.  We'd like it to be
> short, of course.
>
>> Also, the statement "Mandatory arguments to long options are mandatory
>> for short options too." puzzles me
>
> Yes, I don't like that sentence either.  Suggestions for
> improvement are welcome here, too.  Maybe we should just get
> rid of it?  I expect it causes more confusion than it cures.
>