[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Possible enhancement to find(1)
Date: Fri, 10 Jun 2016 17:03:35 +0800 (PHT)
From: Paul Goyette <paul%whooppee.com@localhost>
| Does anyone have suggestions and web-sites for a couple of linux
| distros? I'm not going to check them all... :)
I'd assume they all use the find that's in the gnu findutils which is
in pkgsrc (sysutils/findutils)
But from a man page on a real linux system...
Compares the timestamp of the current file with reference. The
reference argument is normally the name of a file (and one of
its timestamps is used for the comparison) but it may also be a
string describing an absolute time. X and Y are placeholders
for other letters, and these letters select which time belonging
to how reference is used for the comparison.
a The access time of the file reference
B The birth time of the file reference
c The inode status change time of reference
m The modification time of the file reference
t reference is interpreted directly as a time
Some combinations are invalid; for example, it is invalid for X
to be t. Some combinations are not implemented on all systems;
for example B is not supported on all systems. If an invalid or
unsupported combination of XY is specified, a fatal error
results. Time specifications are interpreted as for the arguâ??
ment to the -d option of GNU date. If you try to use the birth
time of a reference file, and the birth time cannot be deterâ??
mined, a fatal error message results. If you specify a test
which refers to the birth time of files being examined, this
test will fail for any files where the birth time is unknown.
which I think means that -newerat -newerct and -newermt are the three
options you're considering adding (please forget birthtime!) Other than
the B cases, adding the full set wouldn't hurt I guess (-newerXX is the
same as the existing -Xnewer of course, except where X==m when it is
The -d option of gnu date is essentially the same as in NetBSD date -d
(though I wouldn't guarantee that our parsedate() always produces the
same results as theirs - in fact it almost certainly doesn't).
Note that that man page extract is useless, and leaves you guessing (which
is what I did) as to what this thing actually means! The text suggests that
both X and Y relate to the reference time, but that would make no sense at
all. I deduce that X is the inode time to check in the current file, and
Y is the reference time, as X==t is invalid.
Main Index |
Thread Index |