| Age | Commit message (Collapse) | Author |
|---|
|
handle infinite depth. Fix docs, tweak dirtree_handle_callback() semantics,
remove dirtree_start() and don't export dirtree_handle_callback(), instead
offer dirtree_flagread(). (dirtree_read() is a wrapper around dirtree_flagread
passing 0 for flags.)
|
|
minor cleanup of previous commit.
|
|
|
|
|
|
I dunno if find -execdir should show depth-first like it's doing, bit given
that ubuntu's treating "+" and ";" the same for execdir... eh?
Also, testing "find toys tests -mindepth 2 -execdir echo {} +" against
the toybox source is easy (and why if (revert) fchdir() is needed), but
adding that to the test suite means making a nontrivial hierarchy of files
to test against (don't wanna use the project source because it's expected
to change in ways that would break the tests)... The old "real world data
vs test data" problem.
|
|
(not finished yet) plus some error message improvements.
|
|
|
|
The segfault was spotted/fixed by Daniel K. Levy back in September, and again by
Isabella Parakiss yesterday. While we're there, remove the environment
size measurement code (the 128k limit was lifted by linux commit b6a2fea39318,
which went into 2.6.22 released July 2007).
|
|
|
|
Includes tests for the new feature, and a failure case for the minimal
perms test as well.
Also some typo fixing / massaging the help text so it fits in 80
columns.
|
|
1) It read st_dev instead of st_mode.
2) It reversed the semantics of absolute vs minimal ('-' prefixed) tests.
Add tests for these, and move the "unterminated -exec" test into the "Still
fails" section because it's still dumping core for me.
|
|
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.
|
|
|
