kilo is k and not K
Dear, in February we had a discussion on the net under the title kilo is k and not K. My initial remark was that the K printout of ls was not according to the Si standard, which only defines k. I understood this could be solved by using the option --si. As the discussion proceded, it became clear that the K in fact does mean 1000 but 2^10 =1024, a power of 2. The M also doesn't mean 10^6, but 2^20 = *1 048 576. *These are computer science units which are much easier to retrieve from the binary operating computer than the decimal Si counterparts. This is defined by the IEC standard: http://physics.nist.gov/cuu/Units/binary.html It specifies Ki as the symbol for kibi-, Mi as the symbol for mibi. According to the standard, K means Ki = kibi. M means Mi = mibi, and so on. K in the displayed -h output represents a kibi-, symbol Ki (see lib/human.c). The conclusion then was that we needed a new ls option --iec like --si The --iec would write out ib prefixes as defined by the IEC standard: Eg: 4,1Ki, 34Mi, ... Would someone be willing to implement this? Best regards, Francky Leyn ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: kilo is k and not K
Philip Rowlands [EMAIL PROTECTED] writes:
There is a slight bug in the documentation of ls
Thanks for mentioning that. Here is a patch:
2007-02-28 Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (Common options): --si outputs M, not MB.
Problem reported by Philip Rowlands in
http://lists.gnu.org/archive/html/bug-coreutils/2007-02/msg00283.html.
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index b313afd..23451fe 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -558,8 +558,8 @@ symbolic link to a directory. @xref{Target directory}.
@itemx --si
@opindex --si
@cindex SI output
-Append an SI-style abbreviation to each size, such as @samp{MB} for
-megabytes. Powers of 1000 are used, not 1024; @samp{MB} stands for
+Append an SI-style abbreviation to each size, such as @samp{M} for
+megabytes. Powers of 1000 are used, not 1024; @samp{M} stands for
1,000,000 bytes. This option is equivalent to
@option{--block-size=si}. Use the @option{-h} or
@option{--human-readable} option if
M doc/ChangeLog
M doc/coreutils.texi
Committed as aac4a5f6d6e238d86130decbb92fd399010834d3
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: kilo is k and not K
Paul Eggert [EMAIL PROTECTED] wrote: Philip Rowlands [EMAIL PROTECTED] writes: There is a slight bug in the documentation of ls Thanks for mentioning that. Here is a patch: 2007-02-28 Paul Eggert [EMAIL PROTECTED] * doc/coreutils.texi (Common options): --si outputs M, not MB. Problem reported by Philip Rowlands in http://lists.gnu.org/archive/html/bug-coreutils/2007-02/msg00283.html. Thanks to both of you. I've applied that. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: kilo is k and not K
Alfred M. Szmidt wrote: Standards should never be followed blindly, and standards should be broken when one thinks one has good reasons. SI also conflicts with POSIX in this case. Not to mention that SI does not define prefixes for all possible units, only SI units, and a byte is not a SI unit. So SI-wise, there is nothing wrong about using k or K as a prefix symbol for `kilo'. From (coreutils)Block size: `k' `K' `KiB' kibibyte: 2^10 = 1024. `K' is special: the SI prefix is `k' and the IEC 60027-2 prefix is `Ki', but tradition and POSIX use `k' to mean `KiB'. Well put. Personally I can't stand the fact that someone decided to make up such a silly sounding word as kibi because they don't like the fact that the contextualized definition of Kilo-Byte was slightly at odds with the SI use of the Kilo prefix. It was well established that a Kilo-Byte was 1024 bytes and was abbreviated as KB well before this silly 'kibi' nonsense started. SI does not define what a kilo-byte is, computer scientists do, and they defined it as 1024. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: kilo is k and not K
SI does not define what a kilo-byte is, computer scientists do, and they defined it as 1024. Being a CS, I like consistency, and I also happen to like kilo-byte == 1000 bytes. :-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
kilo is k and not K
Dear, when you do ls -l -h one sometimes encounters files which have kilo size. ls -l -h then uses K to display this. This is wrong and unallowable. It must be k. You don't have a choice: it is standarised by the SI system as k. See for example http://en.wikipedia.org/wiki/SI . Standards have to be respected regardless of personal preferences. I don't know if this error also occurs for other coreutils. Best regards, Francky Leyn http://users.telenet.be/leyn _ All things trendy for Windows Live Messenger ... http://entertainment.msn.be/funwithmessenger ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: kilo is k and not K
On Mon, 26 Feb 2007, Francky Leyn wrote: when you do ls -l -h one sometimes encounters files which have kilo size. ls -l -h then uses K to display this. This is wrong and unallowable. It must be k. You don't have a choice: it is standarised by the SI system as k. See for example http://en.wikipedia.org/wiki/SI . Standards have to be respected regardless of personal preferences. If you prefer SI-formatted output, the --si option is probably the right choice, and does what you request. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: kilo is k and not K
when you do ls -l -h one sometimes encounters files which have kilo size. ls -l -h then uses K to display this. This is wrong and unallowable. It must be k. You don't have a choice: it is standarised by the SI system as k. See for example http://en.wikipedia.org/wiki/SI . Standards have to be respected regardless of personal preferences. Standards should never be followed blindly, and standards should be broken when one thinks one has good reasons. SI also conflicts with POSIX in this case. Not to mention that SI does not define prefixes for all possible units, only SI units, and a byte is not a SI unit. So SI-wise, there is nothing wrong about using k or K as a prefix symbol for `kilo'. From (coreutils)Block size: `k' `K' `KiB' kibibyte: 2^10 = 1024. `K' is special: the SI prefix is `k' and the IEC 60027-2 prefix is `Ki', but tradition and POSIX use `k' to mean `KiB'. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: kilo is k and not K
(re-adding bug-coreutils - please keep discussion on-list) On Mon, 26 Feb 2007, Francky Leyn wrote: If you prefer SI-formatted output, the --si option is probably the right choice, and does what you request. Implementing this as an option is... The default should be SI. M$ also uses K. Unfortionatly I don't know who to contact there I hope you realise you are wrong and that --si should be the default, and that you will change the program accordingly. The standard is what it is, and the coreutils should respect the standard by default. Having --si be the default would change the well-known output of ls; not only the K/k suffix, but the units themselves are governed by this setting (powers of 1000 vs 1024). But that's not quite your point (that K is never desirable). K in the displayed -h output represents a kibi-, symbol Ki (see lib/human.c), truncated. Arguably this isn't perfect, but it seems a step in the wrong direction to use k to indicate kibi-, contrary to the NIST webpage I'm reading. There is a slight bug in the documentation of ls, What information is listed: `--si' Append an SI-style abbreviation to each size, such as `MB' for megabytes. Powers of 1000 are used, not 1024; `MB' stands for 1,000,000 bytes. This option is equivalent to `--block-size=si'. Use the `-h' or `--human-readable' option if you prefer powers of 1024. I don't believe (rather, have never seen) ls uses a 2-letter suffix for size. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: kilo is k and not K
(re-adding bug-coreutils again) On Mon, 26 Feb 2007, Francky Leyn wrote: [snipped] But that's not quite your point (that K is never desirable). K in the displayed -h output represents a kibi-, symbol Ki (see lib/human.c), truncated. Arguably this isn't perfect, but it seems a step in the wrong direction to use k to indicate kibi-, correct contrary to the NIST webpage I'm reading. Can you give me that URL? What is written wrong there? http://physics.nist.gov/cuu/Units/binary.html specifies Ki as the symbol for kibi-. There is a slight bug in the documentation of ls, What information is listed: `--si' Append an SI-style abbreviation to each size, such as `MB' for megabytes. Powers of 1000 are used, not 1024; `MB' stands for 1,000,000 bytes. This option is equivalent to `--block-size=si'. Use the `-h' or `--human-readable' option if you prefer powers of 1024 I get different output: -h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G) --si likewise, but use powers of 1000 not 1024 That's the manpage, generated from the --help output of ls. The quote I gave is from the info documentation. I think it would be good to incorporate your above explanation in the man page, and correct the bug. It would clarify much. The discrepancy (such as 'MB') doesn't exist in the manpage, only in the info docs. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: kilo is k and not K
(re-adding bug-coreutils again) On Mon, 26 Feb 2007, Francky Leyn wrote: http://physics.nist.gov/cuu/Units/binary.html specifies Ki as the symbol for kibi-. Is this NIST standard acknowledged by ISO, ANSI or others? From the webpage: The complete citation for this revised standard is IEC 60027-2, Second edition, 2000-11, Letter symbols to be used in electrical technology - Part 2: Telecommunications and electronics. I don't know enough about the various standards bodies to say whether they incorporate, acknowledge or merely reference each other's work. Perhaps it is a good idea to allow 2 letter prefixes for the kibi and others, triggered by for example the --NIST option? I doubt that the effort is worthwhile, although anyone is welcome to submit a patch for the maintainer's consideration (N.B. I am not the coreutils maintainer). I suspect that the average user who understands the difference between the suffixes also knows how to obtain their preferred output, and that others suffice with the defaults; --human-readable is arguably not a request for a high degree of precision. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
