| Age | Commit message (Collapse) | Author |
|---|
|
Elliott Hughes found a bug https://android-review.googlesource.com/#/c/170020/
and Daniel K. Levy worked out the problem: the user/group/newer arguments
to find weren't consuming their arguments when not checking the results of
their comparison (because an earlier test had already caused their
parenthetical group to fail). This confused the argument parsing logic
and could lead to segfaults.
I applied a different fix that reorganized the existing tests instead of
adding a new test. (Looks like a big commit but it's mostly whitespace
due to extra curly brackets changing indendentation levels.)
|
|
This fixes the build break, the change to yesno() prototype accidentally got
checked in last commit. (Oops, sorry.)
|
|
|
|
-inum is a commonly implemented extension to search by inode number.
Linux's fs-layer tracepoints log many events in terms of inodes, so
"find -inum" is useful for mapping those events back to specific files.
|
|
symfollow true/false.)
|
|
under traversal. Pass through full flag set in dirtree_add_node(), add
dirtree_start() wrapper to provide symlink-only behavior (avoiding a lot
of DIRTREE_SYMFOLLOW*!!(logic) repeated in callers).
|
|
it didn't activate.
test: find . -name README -exec echo one '{}' ';' -or -exec echo two '{}' ';'
|
|
infrastructure.
|
|
an int. Even though long _is_ 32 bits on a 32 bit systems, gcc warns about it because reasons.
Also, the warning being that "expects int, but type is wchar_t"... no, type
is not wchar_t. Type is probably long. Specify the ACTUAL TYPE, not the random
typedef alias for it. If the translated type _did_ match, there wouldn't
be a warning! (This is why c89 promoted all arguments to int, precisely
so this wasn't a problem.)
|
|
|
|
|
|
we want to redirect both, one, or neither of stdin/stdout.
|
|
|
|
The fact other implementations don't implement "! -mindepth" doesn't mean we can't. Also, find uses +N, N, -N for everything else but this extension doesn't. Also, -depth already had a definition and this has nothing to do with that. It's a poorly thought-out extension, is what I'm saying.
|
|
|
|
mutually-exclusive options -H and -L shall not be considered an error. The last option specified shall determine the behavior of the utility."
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The check for -print vs -print0 was tested before I optimized out the "-" in the strcmps, and I didn't adjust the offset or retest it. (Ooops.)
Also, I wasn't clearing the ! value when descending into parentheticals, so "find . -name blah -o \! \( -stuff -o -thing \)" acted like it had a spurious second ! before -stuff inside the parentheses.
|
|
|
