Date: Wed, 12 Jan 2000 16:21:05 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: current@FreeBSD.ORG Subject: Re: Additional option to ls -l for large files Message-ID: <v04210106b4a296b28cc2@[128.113.24.47]> In-Reply-To: <200001120201.SAA26378@gndrsh.dnsmgr.net> References: <200001120201.SAA26378@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 6:01 PM -0800 1/11/00, Rodney W. Grimes wrote:
>Garance wrote:
> > 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 environment.
>du man page:
> -k Display block counts in 1024-byte (1-Kbyte) blocks.
Note that these commands are talking about block-sizes. Ie, you are
getting a BLOCK count, where the BLOCKSIZE is either 512 (the default
value) or some other number (frequently 1024). If you do choose a
blocksize of 1024, then the number you get happens to be "kilobytes",
but both commands are still talking about a BLOCK count.
In 'ls' we are not talking about a block count, we are talking about
a byte-count. In the past I have written things which do about what
we're talking about here. In the current 'ls', when you see a list
of files as:
-rw-r--r-- 1 gad staff 19672 Dec 11 03:39 HISTORY
-rw-r--r-- 1 gad staff 411 Dec 11 03:47 Makefile.am
-rw-r--r-- 1 gad staff 11492 Dec 12 23:57 Makefile.in
-rw-r--r-- 1 gad staff 2585 Dec 11 03:39 README-bpe
-rw-r--r-- 1 gad staff 1549 Dec 12 23:55 acconfig.h
-rw-r--r-- 1 gad staff 4396 Dec 12 23:57 aclocal.m4
-rw-r--r-- 1 gad staff 2706 Dec 11 03:39 asciiedit.c
-rw-r--r-- 1 gad staff 2046 Dec 11 03:39 asciisrch.c
-rw-r--r-- 1 gad staff 5755 Dec 11 03:39 backup.c
-rw-r--r-- 1 gad staff 35071 Dec 11 03:38 bpe.1
do you really sit there and think "Let's see, that bpe.1 file is
(35071/1024) kilobytes"? Being a slave to the decimal system, I
just read the numbers.
The original message proposed:
a new flag to ls which will together with option -l
change the unit to kilobytes for files larger than
one megabyte, to megabytes for files larger than one
gigabyte and gigabytes for files larger than one terabyte.
In the past, I have done similar things to this, exactly as the
person suggested. If you do not stick to the "10's-based" numbers
for this, things get confusing. Note that you don't switch to
kilobytes until the file is over a megabyte. You end up dealing
with "10's based" values *all* the time, and "2's based" values
some of the time. Ie, consider files:
-rw-r--r-- 1 gad staff 1998246 Dec 11 03:39 asciiedit.c
-rw-r--r-- 1 gad staff 999123 Dec 11 03:39 asciisrch.c
The first one changes because it's over 1 megabyte, but the second
one does not change. So you get:
-rw-r--r-- 1 gad staff 1951k Dec 11 03:39 asciiedit.c
-rw-r--r-- 1 gad staff 999123 Dec 11 03:39 asciisrch.c
Okay now, how many people can look at those lines and immediately
see that the first file is "about" twice the size of the second
file? Probably nobody, not without pulling out a calculator. The
"purity" of using 1024 as a divisor buys one nothing in situations
like this. The problem is that you ARE using the 10's-based number
(in your head) for the "999 thousand" value. And the 1,951K is a
mixture of 10's-based ("1 thousand 951") and 2's-based ("K") values.
Point number two: This option is to keep the number of columns
of the byte-count-field "reasonable". 1 megabyte is 1024*1024.
A 1-megabyte file is therefore 1048576 bytes. If you make the
switch (to "k") at 1048576 bytes, you have used up an extra
column for no good reason. So, it only makes sense to make the
switch at 999,999 bytes. You'll get:
-rw-r--r-- 1 gad staff 8064k Dec 11 03:39 asciiedit.c
-rw-r--r-- 1 gad staff 999999 Dec 11 03:39 asciisrch.c
when the first file is one byte larger than the second file. Again,
the "purity" of going with the "2's based" value is not worth the
confusion caused by it.
This is what my experience has been when I've done similar things.
I actually wrote at least one thing using the 1024 divisor, and
later switched it to using 1000 because using 1024 was just too
confusing. Thus, my suggestion that people should consider going
with the base-10 values.
---
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or drosih@rpi.edu
Rensselaer Polytechnic Institute
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?v04210106b4a296b28cc2>