Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uwm.edu!src.honeywell.com!msi.umn.edu!cs.umn.edu!atc!s5000!nightowl!hawkmoon!det
From: det@hawkmoon.MN.ORG (Derek E. Terveer)
Newsgroups: comp.arch
Subject: Re: UNIX mind-set (was: How wrong is MS-DOS?)
Message-ID: <1991Jan15.091454.880@hawkmoon.MN.ORG>
Date: 15 Jan 91 09:14:54 GMT
References: <1991Jan13.113349.21937@ims.alaska.edu> <11305@lanl.gov>
Organization: Home System (One of the Eternal Champions); Eagan, MN, 55123-2507, USA
Lines: 72

In comp.arch you write:

>> [...]  There
>> are better ways.  Try 'find'.  (You may want to grep the output.)

>Well, 'find' _does_ have filters built-in for similar time related
>filtering (against the advice you have been offering for UNIX tools).

I don't think the arguers have been arguing against *any* kind of extra
capability in a particular tool or even a whole class of tools.  Rather,
an elegant simplicity represented in a modestly greater than minimum
functionality.  If you imagine tools to be little marbles or nodules,
each of which may be connected to each other only at certain points
(kind of like molecules, i'm sure), then we are not arguing for a marble
that has zero, one, or two connection points only.  Zero is a degenerate
case and seems rather useless.

	O   O    O  O  O

One connection point only is almost as useless:

	O--O     	O--O    O--O

Two connection points is what i imagine how you see unix tools in general and,
if that were the case i would tend to agree with you.  

	O--O--O--O--O

But, most unix tools can be used in several different ways so that the same 
end result can be achieved in several different ways, according to the needs of
a particular situation or the druthers of the programmer/user:

	O--O  O
	|     |
	O--O--O--O
	   |
	   O--O--O

This has a much more multi-dimensional feel to it, hmmm?  Building blocks in
which you had to attach everything the same way would truly be dull and not
terribly benificial.  However, look at all the wonderful varieties of brick
buildings there are in the world.  Hardly any of them are the same, and yet,
they are all built with same type of brick.

>I'm happy to see that you regard this as a better way.  However, the
>'find' filters only list files that have been accessed or modified (each
>a separate filter) _since_ 'n' days ago.  There is no way of telling it
						    ^^^^^^
>to list the files that were last modified _before_ a given date.

It is usually potentially dangerous to make statements coached in absolutes.
"No way" is a pretty firm statement in my opinion and, in this case, may be
relatively easily refuted.  I refer you to the man page for find(1) [which
would have benefited you to have read before posting]:

	In the descriptions, the argument "n" is used as a
	decimal integer where "+n" means more than "n",
	"-n" means less than "n", and "n" means exactly "n".

Thus, a sample command to do what I think you claim can't be done with find
is:

find . -mtime -14 -print	#find files modified more than 14 days ago

Or perhaps you meant before a specific date:

touch 1013073077 /tmp/$$
find . ! -newer /tmp/$$ -print	#find files modified before oct 13, 1977
-- 
Derek "Tigger" Terveer	det@hawkmoon.MN.ORG - MNFHA, NCS - UMN Women's Lax, MWD
I am the way and the truth and the light, I know all the answers; don't need
your advice.  -- "I am the way and the truth and the light" -- The Legendary Pink Dots