locate and updatedb were Unix-only (gated behind cfg and stubbed out on
Windows). Make them cross-platform:
- locate: decode raw DB entries via a platform-specific bytes_to_path
(verbatim bytes on Unix, lossy UTF-8 elsewhere), use Metadata::len()
instead of the unix-only size(), and a cross-platform make_symlink in
tests that skips gracefully when symlink creation is unprivileged.
- drop the #[cfg(unix)] gate on the locate module and the
"unsupported on Windows" main stubs for locate/updatedb.
- db_tests: remove #[cfg(not(windows))] gates, write updatedb output to
a tempdir instead of /dev/null, and add a full updatedb->locate
roundtrip test that is platform-independent.
Replace the "early alpha implementation" placeholder help text with a
proper organized reference grouped by category (global options,
operators, positional options, tests, and actions), with brief
descriptions for each entry. The old text was a flat list that hadn't
kept up with the implementation and still carried the "early alpha"
disclaimer.
Also fix a typo in a comment: "- newercm" -> "-newercm".
Drive both utilities end-to-end through their real entry points.
- benches/updatedb_bench.rs: walks a generated tree (~8.5k paths) and
writes a LOCATE02 database, measuring the walk + front-coding + write
(full build and a -regex/-prune variant). Empty prune options keep the
run deterministic regardless of temp_dir location.
- benches/locate_bench.rs: builds the database once via updatedb, then
scans it in -c/count mode so database decoding and pattern matching
dominate (no-match, substring, -b basename, -i ignore-case, -r regex).
Unix-only, matching the locate module's cfg.
The existing CodSpeed workflow picks these up via cargo codspeed build/run.
Introduce criterion benchmarks (via codspeed-criterion-compat) that drive
find and xargs end-to-end through their real entry points, plus a CodSpeed
GitHub Actions workflow to track performance on pushes and PRs.
- benches/find_bench.rs: walks a generated directory tree exercising the
matcher tree (-name/-iname/-regex/-size/-type, grouping, -prune, -printf).
Output is sent to a sink so the directory walk and matching dominate.
- benches/xargs_bench.rs: feeds a corpus via -a and runs 'true' so xargs'
own argument reading/splitting/batching dominates (whitespace, NUL, -n, -s).
- .github/workflows/codspeed.yml: mirrors the uutils/grep setup.
The test from #647 used {} only in an argument, so it passed on
unpatched code. Rewrite it to make the matched entry the
testing-commandline binary and pass {} as the utility name, so the
placeholder must resolve to the entry's path and execute.
* fix: replace {} placeholder in -exec utility name
The {} placeholder was only replaced in arguments to -exec, not in the
utility_name position itself. Running `find -exec {} \;` passed the
literal string "{}" to Command::new, causing "No such file or directory".
Extracted arg parsing into a shared `parse_arg` helper and changed the
`executable` field from String to the existing Arg enum so it undergoes
the same {} replacement as other arguments.
Fixes#614
* test: add test for {} placeholder in utility name
Verify that SingleExecMatcher resolves {} in arguments
when the executable is a known path. Covers the case
where -exec receives {} in argument positions.
---------
Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
The -ok/-okdir prompt rendered the full substituted command, but GNU
find prints a fixed, abbreviated form: "< executable ... pathname > ? "
(literal ..., a space before ?, and always the full entry path even for
-okdir). Match it exactly and update the prompt-format test.
Verified byte-for-byte against GNU findutils 4.10.0.
-ok is like -exec ... ; but prompts the user on stderr before each
invocation and only runs the command if the response is affirmative
(starts with 'y' or 'Y'). -okdir is the corresponding -execdir variant.
Only the ';' terminator is accepted: POSIX does not define -ok ... + and
GNU find rejects it.
Response source: GNU find reads from /dev/tty so that the user's answer
always comes from the real terminal even when stdin is occupied (e.g.
`find -files0-from - -ok rm {} \;` reads paths from stdin, so responses
cannot also come from there). /dev/tty is the POSIX name for a
process's controlling terminal and exists on all Unix-like systems. We
open /dev/tty only when stdin is itself a terminal
(std::io::stdin().is_terminal() == true). When stdin is a pipe or file,
we read from stdin directly — matching BSD find and making scripted use
(and integration tests via pipe_in()) work naturally without any special
environment variable. On Windows, or when /dev/tty cannot be opened, we
likewise fall back to stdin.
Implementation: rather than a separate OkMatcher that duplicated
SingleExecMatcher's fields, constructor, and exec logic, the interactive
prompt is folded into SingleExecMatcher behind an `interactive: bool`
field. `SingleExecMatcher::new_interactive()` constructs the -ok/-okdir
variant; `matches()` adds a guarded block that builds a GNU-find-style
prompt ("< executable arg... >? ") and calls `matcher_io.confirm()`
before executing. If the user declines, the expression is false and the
command is not run. This keeps the arg-parsing, path resolution,
current_dir logic, and error handling in one place so bug fixes apply to
both -exec and -ok.
Dependencies::confirm() trait method: abstracts prompt+read so matchers
remain testable without a real terminal; FakeDependencies uses a
VecDeque of preset responses.
Tests:
- Unit tests (exec_unit_tests.rs): confirmed executes command, declined
skips command and returns false, confirmed but command fails returns
false, -okdir runs in parent dir
- Parser unit tests (matchers/mod.rs): missing-arg errors, missing
semicolon, correct parse, confirm/decline via FakeDependencies
- Integration tests (test_find.rs): pipe_in() makes stdin a pipe so
is_terminal() returns false and responses are read from the pipe;
"y"/"Y"/"yes"/" y" run command, "n" and empty response skip command,
-okdir runs in parent dir, prompt format verified, missing-semicolon
error
Closes https://github.com/uutils/findutils/issues/8.