If -ignore_readdir_race is present, [ENOENT] errors caused by deleting a
file after find has read its name from a directory are ignored.
Formerly, -ignore_readdir_race did nothing.
PR: bin/169723
Submitted by: Valery Khromov and Andrey Ignatov
is in accordance with the information provided at
ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change
Also add $FreeBSD$ to a few files to keep svn happy.
Discussed with: imp, rwatson
This structure is deprecated and only used by ftime(2), which is part of
libcompat. The second argument of get_date() is unused, which means we
can just remove it entirely.
in our find.
The following are nops because they aren't relevant to our find:
-ignore_readdir_race
-noignore_readdir_race
-noleaf
The following aliaes were created:
-gid -> -group [2]
-uid -> -user [2]
-wholename -> -path
-iwholename -> ipath
-mount -> -xdev
-d -> -depth [1]
The following new primaries were created:
-lname like -name, but matches symbolic links only)
-ilname like -lname but case insensitive
-quit exit(0)
-samefile returns true for hard links to the specified file
-true Always true
I changed one primary to match GNU find since I think our use of it violates
POLA
-false Always false (was an alias for -not!)
Also, document the '+' modifier for -execdir, as well as all of the above.
This was previously implemented.
Document the remaining 7 primaries that are in GNU find, but aren't yet
implemented in find(1)
[1] This was done in GNU find for compatibility with FreeBSD, yet they
mixed up command line args and primary args.
[2] -uid/-gid in GNU find ONLY takes a numeric arg, but that arg does the
normal range thing that. GNU find -user and -uid also take a numberic arg,
but don't do the range processing. find(1) does both for -user and -group,
so making -uid and -gid aliases is compatible for all non-error cases used
in GNU find. While not perfect emulation, this seems a reasonable thing
for us.
not on the top-level -and sequence, e.g. inside of ! or -or.
Create a separate linked list of all active -exec {} + primaries and
do the last execution for all at termination.
PR: bin/79263
Submitted by: Jilles Tjoelker <jilles@stack.nl>
MFC after: 7 days
the depth of the current file relative to the starting
point of the traversal is n. The usual +/- modifiers
to the argument apply.
- while I'm here, fix -maxdepth in the case of a depth-first
traversal
Print the top ten maintainers of python module ports
(works with p5-* too):
find /usr/ports -depth 2 \! -name 'py-*' -prune -o \
-depth 3 -name Makefile -execdir make -VMAINTAINER \; \
| sort | uniq -c | sort -nr | head
PR: 66667
Reviewed by: ru, joerg
Approved by: joerg
MFC after: 2 weeks
ACLs. This is similar to what ls(1) can do. It is handy to
have it so that it can be used in conjunction with
"-exec setfacl {} \;" (to find(1)), among others.
This is the submitter's patch, but slightly modified.
PR: bin/65016
Submitted by: Christian S.J. Peron <maneo@bsdpro.com>
-anewer
-cnewer
-mnewer
-okdir
-newer[acm][acmt]
With it, you can form queries like
find . -newerct '1 minute ago' -print
As an extra bonus, the program is ANSI-fied - the original version
relies on some obscure features of K&R C.
(This PR was submitted in 1999, and the submittor has kept the patch
updated ever since, hats off for him guys, and how about you close a PR ??)
PR: 9374
Submitted by: Martin Birgmeier <Martin.Birgmeier@aon.at>
-E Interpret regular expressions followed by -regex and -iregex op-
tions as extended (modern) regular expressions rather than basic
regular expressions (BRE's). The re_format(7) manual page fully
describes both formats.
-iname pattern
Like -name, but the match is case insensitive.
-ipath pattern
Like -path, but the match is case insensitive.
-regex pattern
True if the whole path of the file matches pattern using regular
expression. To match a file named ``./foo/xyzzy'', you can use
the regular expression ``.*/[xyz]*'' or ``.*/foo/.*'', but not
``xyzzy'' or ``/foo/''.
-iregex pattern
Like -regex, but the match is case insensitive.
These are meant to be compatible with other find(1) implementations
such as GNU's or NetBSD's except regexp library differences.
Reviewed by: sobomax, dcs, and some other people on -current
is empty. There doesn't appear to be another easy way to do this.
mobile# mkdir foo
mobile# mkdir foo/bar
mobile# mkdir bar
mobile# find . -empty
./foo/bar
./bar
behave as in GNU find (and of course as described in the manual page
diff included). I think these options would be useful for some people.
Some missing $FreeBSD$ tags are also added.
The patch was slightly modified (send-pr mangling of TABS).
PR: bin/18941
Submitted by: Ben Smithurst <ben@scientia.demon.co.uk>
I added $FreeBSD$ whicle I was here. The patch wasn't usable anymore
due to its age so I adapted it.
PR: bin/3648
Submitted by: Martin Birgmeier <mbirg@austria.ds.philips.com>
doesn't know about getvfsbyname() and the vfsconf structure. This
disables the -fstype option if compiled with a pre-processor that
defines __NetBSD__. With the FreeBSD built pre-processor, find can only
be built with the FreeBSD libc. So when running with a NetBSD kernel,
FreeBSD's libc will have to return ENOSYS for things that NetBSD
doesn't support. That's life in a hybrid world.
in question. This change and the fts changes should be merged into 2.2-stable
as soon as they are vetted in -current. This should allow cleaning of files
in /tmp to be reneabled.
Obtained from: OpenBSD
goes to a fair degree of trouble to enable something like this to
be safe: cd /tmp && find . -mtime +7 -delete
It removes both files and directories. It does not attempt to remove
immutable files (an earlier version I showed to a few people did a chflags
and tried to blow away even immutable files. Too risky..)
It is thought to be safe because it forces the fts(3) driven descent to
only do "minimal risk" stuff. specifically, -follow is disabled, it does
checking to see that it chdir'ed to the directory it thought it was
going to, it will *not* pass a pathname with a '/' character in it to
unlink(), so it should be totally immune to symlink tree races. If it runs
into something "fishy", it bails out rather than blunder ahead.. It's better
to do that if somebody is trying to compromise security rather than risk
giving them an opportunity. Since the unlink()/rmdir() is being called
from within the current working directory during the tree descent, there
are no fork/exec overheads or races.
As a side effect of this paranoia, you cannot do a
"find /somewhere/dir -delete", as the last argument to rmdir() is
"/somewhere/dir", and the checking won't allow it. Besides, one would use
rm -rf for that case anyway. :-)
Reviewed by: pst (some time ago, but I've removed the immutable file
deletion code that he complained about since he last saw it)
