Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!xanth!mcnc!duke!bet
From: bet@orion.mc.duke.edu (Bennett Todd)
Newsgroups: comp.unix.wizards
Subject: Re: Filename length statistics
Message-ID: <14752@duke.cs.duke.edu>
Date: 14 Jun 89 20:51:46 GMT
References: <19976@adm.BRL.MIL> <4530@ficc.uu.net> <14749@duke.cs.duke.edu>
Sender: news@duke.cs.duke.edu
Reply-To: bet@orion.mc.duke.edu (Bennett Todd)
Organization: Diagnostic Physics, Raddiology, DUMC
Lines: 21
In-reply-to: bet@orion.mc.duke.edu (Bennett Todd)

In article <14749@duke.cs.duke.edu>, I wrote:
>[...]
>The 14-character long names only handle ~83% of my filenames (this
>includes directory names, and in particular includes "." and ".." for
>every directory, so there is some structural weighting acting against my
>statistics here).

...which is of course completely wrongo. Thanks to Matt Crawford for
pointing this out to me in a very polite letter. Sorry about this
misinformation. Find(1) is of course smart enough to refrain from
reporting "." and ".."; indeed, I shouldn't have even had to check to
see what its behavior is. Upon thinking about it even briefly, it
becomes obvious that many, even most of the uses to which find(1) is put
would be broken if it didn't omit "." and ".." (and emitted them :-).

-Bennett
bet@orion.mc.duke.edu

	(1) Start brain
	(2) Engage mouth
	Do not perform in reverse order.