uutils findutils rewrites find, xargs, locate and updatedb in Rust

Four binaries, one crate, and a stated drop-in goal

The scope is small and specific: xargs, find, locate and updatedb, described as a Rust implementation of GNU findutils with the stated goal of being a full drop-in replacement of the original commands. The Cargo manifest confirms the shape, with four binary targets pointing at src/find/main.rs, src/locate/main.rs and siblings under src. The package is published on crates.io, and the version in the manifest is 0.11.0 while the most recent tagged release is 0.10.0 from 2026-08-03, so the crate in the repository is ahead of the last published artefact. That gap is normal for a workspace where the release is cut from a tag, but it means a cargo install of the crate gives you the release, while a checkout gives you whatever main currently holds.

Conformance is measured against the GNU and BFS test suites in public graphs

The most useful thing in this repository is not the code, it is the measurement. The README points at two tracking repositories, one plotting the evolution of the GNU test suite results over time and one plotting the BFS results, both under uutils/findutils-tracking. A compatibility claim for a command line tool is only worth what its test suite says, and here the suite is the upstream one rather than a hand written approximation. Running the GNU suite is a script in the util directory.

bash util/build-gnu.sh

A single test can be run by passing its path.

bash util/build-gnu.sh tests/misc/help-version.sh

Because the results are published as graphs over time, a reader can see which parts of the suite pass and when regressions appeared, instead of taking a compatibility statement on trust.

The BFS suite covers breadth-first traversal, a different tree order

There is a second conformance target, and the reason it exists is about semantics rather than coverage. bfs is a variant of the UNIX find command that operates breadth-first rather than depth-first, and it ships its own test suite. The project runs it through a parallel script.

bash util/build-bfs.sh

And a specific test can be selected by name.

bash util/build-bfs.sh posix/basic

Testing against two suites with different traversal orders is a stronger check than one, because a find implementation that assumes a single ordering order of results tends to fail when the expected output order changes. For anyone writing scripts that depend on the order in which find emits paths, this is the part of the test infrastructure that matters most.

Expression errors point at the offending argument

One behaviour is called out separately from the compatibility story, and it is a genuine improvement rather than a bug fix. At a terminal, find underlines the argument at fault in expression errors, and the README links to the documentation on rich expression diagnostics for the details. The conventional behaviour when you write a malformed find expression is a message that names the problem without pointing at where in your command line the problem is. Underlining the argument in place is a small change with a real effect on how fast a human can correct a long expression, and it is the kind of difference that a pure conformance suite would never require.

The dependency list shows the scope of the platform work

Cargo.toml shows what implementing these commands on several platforms actually required. uucore at version 0.12.0 provides the shared utilities with features for diagnostics, entries, filesystem access, extended attributes and mode handling, and it comes from the same uutils ecosystem. walkdir handles directory traversal, clap 4.6 with the env feature parses the command line, nix supplies Unix system calls with fs and user features, faccess checks permissions, and both onig and regex are present, which suggests pattern matching paths that need more than one flavour. The manifest also carries a WASI specific dependency block, and the comment explains why: uucore depends on rustix without its std feature, which leaves uucore::fs unable to build for WASI, so rustix is added with std enabled through feature unification until uucore does it itself.

Benchmarks exist for every binary, and packaging targets are declared

The repository carries a benches directory and the manifest defines four benchmark targets with the harness disabled, one for find, one for xargs, one for updatedb and one for locate. Development dependencies include criterion, shipped here as the codspeed-criterion-compat package, along with assert_cmd, rstest, tempfile, filetime and uutests, which is the uutils shared test helper. The packaging side is declared too. A binstall metadata block gives the release download URL template, the binary directory layout, the txz archive format, and an override that switches the Windows MSVC target to zip, because the tarball format there needs a different archive. For a tool distributed as four separate binaries across several platforms, that kind of detail is where install scripts usually break.

MIT licensing and a release cadence of a few minor versions a year

The licence is MIT, which keeps the licensing question trivial for anyone embedding these binaries in a build pipeline, and there is a LICENSE file at the top of the repository along with a SECURITY.md, a CODE_OF_CONDUCT.md and a CONTRIBUTING.md. The recent release history is 0.10.0 on 2026-08-03, 0.9.1 on 2026-06-22 and 0.9.0 on 2026-06-08, so minor versions land every few weeks. The repository is not archived and the last push was on 2026-10-19. The other top level entries are typical of a well-organised project: a pre-commit configuration, a dist-workspace.toml, a DEVELOPMENT.md, a docs directory, a test_data directory and a util directory holding the shell scripts that drive the external test suites.

Editorial conclusion

Adopt uutils findutils if you want one implementation of find, xargs, locate and updatedb that you can build and pin from source, and if you are willing to watch the conformance graphs before trusting a rarely used flag. Skip it if your scripts depend on an obscure GNU extension that the tracking data does not yet cover, since the goal is drop-in behaviour and the gaps are visible in the results rather than hidden. Verify first that the four binaries you need are on your PATH after building, that the GNU test suite run for your target completes for the areas you rely on, and that the crate version you pin matches the behaviour your scripts expect, because the manifest version moves ahead of the published release tags.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. uutils/findutils on GitHub