Date: Wed, 12 Jan 2000 08:16:46 -0500 From: Tom Embt <tom@embt.com> To: Brad Knowles <blk@skynet.be>, Warner Losh <imp@village.org>, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: MichaelV@EDIFECS.COM (Michael VanLoon), joerg@cs.waikato.ac.nz, current@FreeBSD.ORG Subject: Re: Additional option to ls -l for large files Message-ID: <3.0.3.32.20000112081646.0161fcb8@mail.embt.com> In-Reply-To: <v04220801b4a20f42cd3a@[195.238.1.121]> References: <200001112314.QAA07511@harmony.village.org> <200001112249.OAA25732@gndrsh.dnsmgr.net> <200001112314.QAA07511@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>> kB and kiB are the proper abreviations, not KB and KiB. I don't know >> if miB or MiB is correct, likely MiB. > > I always thought it was "k/m/b = 1,000/1,000,000/1,000,000,000" >and "K/M/G = 2^10/2^20/2^30". Or was this just some convention I >learned somewhere that I mistakenly thought of as an actual accepted >rule? But, with the letter "M" for example, m = milli-, M = mega- Like Donn was saying, there's no reason not to do it every way. Have the different options selectable by either an environmental variable or a command line switch. I'd vote for default behavior as the traditional: K = 2^10 M = 2^20 G = 2^30 T = 2^40 P = 2^50 .. but also have options for showing the entire unclipped file length, "binary mode international abbreviation standard", and maybe even scientific or engineering notation (for kicks). Tom Embt tom@embt.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.20000112081646.0161fcb8>