As per POSIX, the -exec ... {} + primary always returns true, but a non-zero
exit status causes find to return a non-zero exit status itself. GNU does
the same, and also for -execdir ... {} +.
It does not make much sense to return false from the primary only when the
child process happens to be run.
The behaviour for -exec/-execdir ... ; remains unchanged: the primary
returns true or false depending on the exit status, and find's exit status
is unaffected.
fts_read() leaves errno unchanged on EOF and sets it on error, so set errno
to 0 before calling it. Also, don't trust finish_execplus() to leave errno
unchanged.
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
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
hack, thereby allowing future extensions to the structure (e.g., for extended
attributes) without rebreaking the ABI. FTSENT now contains a pointer to the
parent stream, which fts_compar() can then take advantage of, avoiding the
undefined behavior previously warned about. As a consequence of this change,
the prototype of the comparison function passed to fts_open() has changed
to reflect the required amount of constness for its use. All callers in the
tree are updated to use the correct prototype.
Comparison functions can now make use of the new parent pointer to access
the new stream-specific private data pointer, which is intended to assist
creation of reentrant library routines which use fts(3) internally.
Not objected to in spirit by: -arch
-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
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>
