Re: Additional option to ls -l for large files
Sorry, I will slow down my reading and stop flipping 2^10 into 10^3. From: Rodney W. Grimes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 12, 2000 9:53 PM [in regards to a previous post preferring base-10 for K and M units...] I'm sorry but I would find it non-obvious and more confusing. When ls or a similar disk/memory utility tells me xxxK or xxxM, I would expect it to be in 2^10 or 2^20 units. To appear otherwise would surprise me. I guess you get suprised a lot then. The only folks that I know of who regulary use K and M as base 10 when talking about disk and memory are the disk drive manufactures. Does you machine have 128MB or 134MB. You must have missed this earlier in the thread All of the boot time reporting is in 2^20 MB: ad0: 3079MB (6306048 sectors), 6256 cyls, 16 heads, 63 S/T, 512 B/S Due the math if you doubt me, oh, and Quantum calls this a 3.2G disk drive :-) I think if you re-read my post you'll find that we are in vehement agreement. I have doned the cap |:-) -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
On 2000-Jan-13 16:45:45 +1100, "Rodney W. Grimes" [EMAIL PROTECTED] wrote: All of the boot time reporting is in 2^20 MB: ad0: 3079MB (6306048 sectors), 6256 cyls, 16 heads, 63 S/T, 512 B/S Due the math if you doubt me, oh, and Quantum calls this a 3.2G disk drive :-) 6256*16*63*512 = 3,228,696,576 ~= 3.2*10^9 or 3079.1*2^20 or 3.007*2^30 Some manufacturers note that `1GB = 10^9 bytes' in the fine print. Quantum can also state (correctly) that they are complying with the SI standard. This is still an improvement on the old approach of quoting _unformatted_ capacity (which is ~50% more). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
At 7:57 PM -0500 2000/1/11, Mike Fisher wrote: Why not use Knuth's (good) suggestion for differentiating these prefixes? http://www-cs-faculty.stanford.edu/~knuth/news99.html Blech. The prefixes should be aware of the nature of the term to which they are being applied. For bytes, it is natural to use base two exponents, and therefore there should be no confusion between KB = 1024 bytes and km = 1000 meters. I really think it is (or should be) that simple. Now I guess I'm going to have to go devote a web page to this topic and tell people about it. I'm getting really sick and bloody tired of all this BS Of course, this is totally unrelated to -current, so follow-ups should be sent to -chat. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
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 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
In message v04220801b4a20f42cd3a@[195.238.1.121] Brad Knowles writes: : 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? This is wrong. k is Si for 10^3, but m is 10^-3. M is 10^6 and G is 10^9. K was used for a long time for 2^10. M and G were overloaded to mean 2^20 and 2^30, but some people even in the industry broke ranks (the disk drive makers) and were able to claim larger disk sizes by using the Si meaning of M rather than the CS meaning of M. I've rarely seen your meanings used anywere, except for the k vs K thing. You may want to take a look at http://physics.nist.gov/cuu/Units/binary.html for definitions of the binary stuff. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
Folks, this is getting a little silly. Can't we cut all the esoteric mumbo-jumbo and agree to do it the same way that gnuls and our own existing df do it? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
Personally, I'd much prefer to simply use separator characters like this: -rw--- 1 olli olli 211,602,776 Nov 28 23:09 S1E1.mpg This makes it very easy to recognize the size, and you still have the exact number of bytes, not rounded. It's even possible to to respect the locale setting (LC_NUMERIC) and use the appropriate character as separator. Just my 0.02 Euro. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
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 staff411 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 staff999123 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 staff999123 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 staff99 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 = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
On Wed, 12 Jan 2000 16:21:05 -0500, Garance A Drosihn [EMAIL PROTECTED] said: In 'ls' we are not talking about a block count, we are talking about a byte-count. ls -s -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
At 4:51 PM -0500 1/12/00, Garrett Wollman wrote: On Wed, 12 Jan 2000, Garance A Drosihn [EMAIL PROTECTED] said: In 'ls' we are not talking about a block count, we are talking about a byte-count. ls -s Hmm, valid point. 'ls -l' is not using a block count though, and so all of my previous comments still make sense for 'ls -l' and the new option. 'ls -s' and the new option should follow a block count, but then 'ls -s' is showing a block count for ALL files that it lists. The examples I gave in my previous message don't end up as confusing for 'ls -s' as they do for 'ls -l'. Maybe the new option should not even apply to 'ls -s'? I have no preference for 'ls -s' behavior. In any case, I'm still saying that in practice, people will find it less confusing if 'ls -l' used 1000 as the divisor, not 1024. Or at least, I found it less confusing, when I have done this same thing. Yes, it may be "more pure" to use 1024 when comparing 'ls' listings to block counts, but it is less confusing WITHIN a single 'ls -l' listing if all the numbers are decimal, and not some combination of base-10 and base-2. 'ls -l' listings (without the -s...) are already a problem when comparing to 'du' or 'df' listings. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
On Wed, Jan 12, 2000 at 04:21:05PM -0500, Garance A Drosihn wrote: 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 staff999123 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 Point taken. What about: -rw-r--r-- 1 gad staff 1951k Dec 11 03:39 asciiedit.c -rw-r--r-- 1 gad staff999123 Dec 11 03:39 asciisrch.c or: -rw-r--r-- 1 gad staff 1951k Dec 11 03:39 asciiedit.c -rw-r--r-- 1 gad staff999123 Dec 11 03:39 asciisrch.c I can see Oliver's proposal making a lot of sense here, the more since we avoid the discussion about K/M/G/T being base 2 or 10. Joerg -- Joerg B. MicheelEmail: [EMAIL PROTECTED] Waikato Applied Network DynamicsPhone: +64 7 8384794 The University of Waikato, CompScience Fax: +64 7 8384155 Private Bag 3105Pager: +64 868 38222 Hamilton, New Zealand Plan: TINE and the DAG's To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
On 2000-Jan-13 09:54:17 +1100, Joerg Micheel [EMAIL PROTECTED] wrote: -rw-r--r-- 1 gad staff 1951k Dec 11 03:39 asciiedit.c -rw-r--r-- 1 gad staff999123 Dec 11 03:39 asciisrch.c You still need to mentally re-align the numbers before you can compare the sizes. -rw-r--r-- 1 gad staff 1951k Dec 11 03:39 asciiedit.c -rw-r--r-- 1 gad staff999123 Dec 11 03:39 asciisrch.c This reduces the number of significant figures to a level which allows a quicker grasp of the size, but doesn't resolve the column- width problem. The other option would be to require a flag to ls to trigger the behaviour - in which case all the files use the same suffix: $ ls -l -rw-r--r-- 1 gad staff 1951456 Dec 11 03:39 asciiedit.c -rw-r--r-- 1 gad staff999123 Dec 11 03:39 asciisrch.c $ ls -lK -rw-r--r-- 1 gad staff 1951k Dec 11 03:39 asciiedit.c -rw-r--r-- 1 gad staff999k Dec 11 03:39 asciisrch.c $ ls -lM -rw-r--r-- 1 gad staff 2M Dec 11 03:39 asciiedit.c -rw-r--r-- 1 gad staff 1M Dec 11 03:39 asciisrch.c Conveniently, -K, -M and -G are still available. Unfortunately, -T and -P are taken (though -p isn't). I'll stay out of the 2^x vs 10^y debate. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
On Wed, 12 Jan 2000 17:45:51 -0500, Garance A Drosihn [EMAIL PROTECTED] said: Yes, it may be "more pure" to use 1024 when comparing 'ls' listings to block counts, but it is less confusing WITHIN a single 'ls -l' listing if all the numbers are decimal, and not some combination of base-10 and base-2. OK, let's try again. BLOCKSIZE=1000 ls -s Actually, this doesn't quite do what one would want, either -- the remainder is always rounded up, so a file which takes 1024 bytes even shows up as two 1000-blocks. However, it does do the right thing for large block sizes: wollman@khavrinen$ BLOCKSIZE=1M df / Filesystem 1M-blocks UsedAvail Capacity Mounted on /dev/wd0s1a 93 28 5634%/ wollman@khavrinen$ BLOCKSIZE=100 df / Filesystem 100-blocks UsedAvail Capacity Mounted on /dev/wd0s1a 97 30 5934%/ -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
[Charset iso-8859-1 unsupported, filtering to ASCII...] I'm sorry but I would find it non-obvious and more confusing. When ls or a similar disk/memory utility tells me xxxK or xxxM, I would expect it to be in 2^10 or 2^20 units. To appear otherwise would surprise me. I guess you get suprised a lot then. The only folks that I know of who regulary use K and M as base 10 when talking about disk and memory are the disk drive manufactures. Does you machine have 128MB or 134MB. You must have missed this earlier in the thread All of the boot time reporting is in 2^20 MB: ad0: 3079MB (6306048 sectors), 6256 cyls, 16 heads, 63 S/T, 512 B/S Due the math if you doubt me, oh, and Quantum calls this a 3.2G disk drive :-) -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
I'm currently dealing with an increasing set of *very* large files, most of them in the order of gigabytes. It becomes impossible to figure the size of a file with ls -l with 9 or more digits displayed. I would propose 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. A 'k', 'm' or 'g' respectively should be appended. Would such a patch find the blessing of the team and the maintainer of ls ? 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. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
On Wed, Jan 12, 2000 at 11:04:56AM +1300, Joerg Micheel wrote: [ls whith sizes in k,M] Would such a patch find the blessing of the team and the maintainer of ls ? You could try gnuls -h -fn- -- ~/.signature not found: wellknown error 42 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
On Tue, Jan 11, 2000 at 11:23:54PM +0100, Frank Nobis wrote: On Wed, Jan 12, 2000 at 11:04:56AM +1300, Joerg Micheel wrote: [ls whith sizes in k,M] Would such a patch find the blessing of the team and the maintainer of ls ? You could try gnuls -h As much as I tried - this is not within GNU fileutils. Which version and package are you referring to ? Are you using a FreeBSD system ? Joerg PS: Frank, you are unreachable directly, so I had to post back to the list. relay.orbs.net is blocking your domain, please fix it. -- Joerg B. MicheelEmail: [EMAIL PROTECTED] Waikato Applied Network DynamicsPhone: +64 7 8384794 The University of Waikato, CompScience Fax: +64 7 8384155 Private Bag 3105Pager: +64 868 38222 Hamilton, New Zealand Plan: TINE and the DAG's To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
Joerg Micheel wrote: On Tue, Jan 11, 2000 at 11:23:54PM +0100, Frank Nobis wrote: On Wed, Jan 12, 2000 at 11:04:56AM +1300, Joerg Micheel wrote: [ls whith sizes in k,M] Would such a patch find the blessing of the team and the maintainer of ls ? You could try gnuls -h As much as I tried - this is not within GNU fileutils. Which version and package are you referring to ? Are you using a FreeBSD system ? Joerg see packages-3.4-release (or whatever version you run) : gnuls-4.0.tgz regards, -- Jean Louis Ntakpe Texas Instruments - Freising [EMAIL PROTECTED] Wafer Fab Automation Group [EMAIL PROTECTED]Haggerty Str. 1 D-85350 Freising, Germany Phone +49 8161 80-3816 Fax +49 8161 80-3762 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
On Wed, Jan 12, 2000 at 11:35:28AM +1300, Joerg Micheel wrote: On Tue, Jan 11, 2000 at 11:23:54PM +0100, Frank Nobis wrote: On Wed, Jan 12, 2000 at 11:04:56AM +1300, Joerg Micheel wrote: [ls whith sizes in k,M] Would such a patch find the blessing of the team and the maintainer of ls ? You could try gnuls -h As much as I tried - this is not within GNU fileutils. Which version and package are you referring to ? Are you using a FreeBSD system ? /usr/ports/misc/gnuls -Chris -- [EMAIL PROTECTED] [EMAIL PROTECTED] Abbotsford, BC, Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
[Charset windows-1252 unsupported, skipping...] Arghh... windblows... I'm currently dealing with an increasing set of *very* large files, most of them in the order of gigabytes. It becomes impossible to figure the size of a file with ls -l with 9 or more digits displayed. I would propose 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. A 'k', 'm' or 'g' respectively should be appended. Would such a patch find the blessing of the team and the maintainer of ls ? 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 What is this "binary mode international abbreviation standard"? See above... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
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). --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
Garance A Drosihn wrote: [trimmed list of recipients to just -current] 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). Or else we could put both in. There could be either a command-line option or env variable set that selects between decimal (true metric) or powers of two (computer metric, or whatever). - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 11 Jan 2000, Rodney W. Grimes wrote: 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 Why not use Knuth's (good) suggestion for differentiating these prefixes? http://www-cs-faculty.stanford.edu/~knuth/news99.html Page down to the ``What is a kilobyte?'' section. Note where he says that bad ideas don't have to be accepted simply because they are the standard. - -- Mike "The man who puts all the guns and all the decision-making power into the hands of the central government and then says, 'Limit yourself'; it is he who is truly the impractical utopian." -- Murray Rothbard -BEGIN PGP SIGNATURE- Version: PGP for Personal Privacy 5.0i Comment: Charset: noconv iQA+AwUBOHvRa+G+Jfm/z6tNEQKeQgCYsgMjGJuEIzSdGuOZhzD9bGyCEACfWGXU If3lwGo63sD2JmuIWRkvwbw= =gxx6 -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
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) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
On Tue, Jan 11, 2000 at 06:01:53PM -0800, Rodney W. Grimes wrote: (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 Don't forget our new ``df -h''. I'm working with mharo to get "-h" added to `du'. I guess we should add it to `ls' too. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Additional option to ls -l for large files
On Tue, 11 Jan 2000, Donn Miller wrote: Or else we could put both in. There could be either a command-line option or env variable set that selects between decimal (true metric) or powers of two (computer metric, or whatever). What about making ls sensitive to $BLOCKSIZE, but only if enabled with a command line option? This way you could get sizes listed in 2.5 megabytes if you so desired... - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
