Date: Tue, 11 Jan 2000 18:01:53 -0800 (PST) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: drosih@rpi.edu (Garance A Drosihn) 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: <200001120201.SAA26378@gndrsh.dnsmgr.net> In-Reply-To: <v04210102b4a16c6972c4@[128.113.24.47]> from Garance A Drosihn at "Jan 11, 2000 06:29:08 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> At 2:49 PM -0800 1/11/00, Rodney W. Grimes wrote:
> > > >Another thing that ``works for me''. Only make it ki, mi, and gi
> > > >to fit with the new binary mode international appreviation standards,
> > > >unless of cource you use base 10 divisors.
> > >
> > > Why not KB, MB or GB, since that's what you're actually reporting?
> >
> >Because KB MB and GB mean different things than KiB MiB and GiB.
> >
> >K = 10^3, Ki = 2^10
> >M = 10^6 Mi = 2^20
> >G = 10^9 Gi = 2^30
>
> personally, I'd just as soon use K, M, and G and have it mean
> the base-10 values. If I'm looking at a decimal number for one
> file (because it's small enough), I don't want a base-2 version
> of the similar number for some other (larger) file in the same
> listing.
>
> (ie, whatever letters you use, please just divide the values
> by 1000 instead of 1024).
Please don't, there is already far to much precedence in both the
computing world and other commands (df -k and du -k come to mind
right off the top of my head, sysinstall uses them in the disklabel
and partition editor, etc)
df man page:
-k Use 1024-byte (1-Kbyte) blocks rather than the default. Note
that this overrides the BLOCKSIZE specification from the environ-
ment.
du man page:
-k Display block counts in 1024-byte (1-Kbyte) blocks.
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net
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?200001120201.SAA26378>