stealth technology for find(1)

[J Greely]

In article <3608 at mentor.cc.purdue.edu> dls at mentor.cc.purdue.edu
 (David L Stevens) writes:
>	Another find(1) question that we're addressing locally is the
>unintuitive meaning of numbers in the comparisons. As it is, there are
>three forms ("n", "+n" and "-n").

What's unintuitive?  If I say "-mtime +1", I certainly hope it is
interpreted as "two or more days".  I never had a problem with the
current style: 0 is the past twenty-four hours, +0 is anything before
that, and -1 is 0.  As long as the units are full days, this behavior
is correct.  If you want a different behavior, extend the syntax to
floating point (+1.0 is what you seem to be asking for).  In the long
run, you'll probably find that more useful.

  Of course, if you really want to have fun, check out the paper in
the Summer USENIX proceedings (whose title isn't handy at the moment,
unfortunately), detailing the implementation of a portable file system
tree walking library.  Their find replacement, "tw", has a very handy
awk-like language embedded into it, allowing truly fun things to be
done to files.

[suggested changes]
>	3) to match "n", a file should be +/- a reasonable epsilon.
>		(current: n+1 sec to n+23 hours 59 mins 59 secs)
>		I suggest an hour, so files 23.00.01-25.00.59 would be
>		considered an "exact" day-old match, but a file that's
>		1 day, 22 hours old would not.

Ugh.  You're better off going to floating point.  Magical fudging like
this from something that claims to work in "days" could make for
confusing results.

>	The most obtuse example is a file that's 1 second short of two days
>old and won't match on "+1", even though the file is in fact 1.99998 days old.
Most people'd call that 2, but anyone'd call it >1.

But a computer will insist that, by the supplied definition of "day",
that file is one day old.  It ain't 0 days old, it ain't 2 days or
older, so it's 1.
-=-
J Greely (jgreely at cis.ohio-state.edu; osu-cis!jgreely)