fselect: SELECT name, size FROM your filesystem WHERE it actually helps

A SELECT against the directory tree

The core idea is that file search already has a query shape, columns, sources, predicates and ordering, so fselect adopts it directly, fselect with a column list, from one or more roots, where an expression, then group by, having, order by, limit and offset, and into an output format. The grammar is described honestly as SQL-like, not real SQL, but highly relaxed, a human friendly dialect rather than a parser for the standard. The first example sets the tone:

fselect size, path from /home/user where name = '*.cfg' or name = '*.tmp'

Quoting is flexible for the shell realities of each platform, Windows users may omit the quotes around globs, the whole query can be quoted as one argument, and paths with spaces work through single quotes, backticks or escaped quotes, three spellings of the same necessity.

Sizes in units, in three formats

Size handling shows the practical bent. Predicates accept human units, size gt 2g, size = 5m, size lt 8k, and a between range like 5mb and 6mb, while the column list offers three renderings, size as raw bytes, fsize, and hsize as a human readable form, plus abspath for absolute paths. Complex predicates compose with parentheses, one example asking for tmp files of zero bytes or cfg files over a million bytes in a single where clause. The unit suffixes and the three output formats together cover both the scripting case, where bytes must be exact and comparable, and the interactive case, where a person wants to see 4.2M, without a post-processing pipe in between.

Subqueries, including one in FROM

The feature that lifts fselect past a glob wrapper is subquery support for the IN and EXISTS operators, and the examples nest aggressively, a four deep chain selecting names from one directory where size matches a subquery on another whose names match a third whose modification times come from a fourth. The EXISTS form aliases both sides, files from /data as data where exists a matching name in /backup as backup, effectively a join between directory trees. And a subquery can serve as the FROM source of the outer query, selecting from the paths found at depth 2 in /projects where size exceeds 100, then filtering those by name, a pipeline expressed as one statement. Comparing results across several directories is the use case the project names for this, and it is the one traditional find never solved.

Aggregates, and curly braces if you want them

Aggregate functions follow SQL's vocabulary, MIN, MAX, AVG, SUM and COUNT over a directory in one query, with a small ergonomic flourish, curly braces may replace parentheses and even mix with them, MIN(size) alongside MAX{size} in the same select list. Scalar functions cover formatting and extraction, LOWER and UPPER for case, LENGTH, and date parts like YEAR of the modification time, composable as MIN(YEAR(modified)) to get the year of the oldest file in a tree. Group by and having clauses complete the aggregate story, so questions like how much space each extension consumes in a directory are one query rather than a pipeline of sort and awk. It is the statistics layer that makes the SQL metaphor worth its parsing cost.

It reads EXIF, audio headers, and archive contents

The predicate columns reach well past stat. Images are searchable by width and height and by EXIF metadata, audio files by their format tags across MP3, FLAC, Ogg Vorbis, Opus, M4A and AAC, WAV, AIFF, APE, WavPack, Musepack and Speex, and searches run within archives, not just alongside them. On Unix systems, extended file attributes, POSIX ACLs and Linux capabilities are queryable, the columns a security auditor or a puzzled sysadmin actually needs. Files can be matched by hash, by MIME type detected through content rather than extension, and shortcuts exist for common file types so everyday queries avoid spelling out globs. The dependency list in Cargo.toml backs every claim, lofty for audio tags, kamadak-exif, imagesize, mp4parse and matroska for media dimensions, tree_magic_mini for MIME, the sha1, sha2 and sha3 families for hashing, zip for archives, xattr and libc for the Unix attributes.

Index-backed speed, and an interactive mode

For large filesystems, fselect can lean on existing indexes instead of walking trees, voidtools Everything on Windows and plocate on Linux, enabled at build time with --features everything or --features plocate and activated per run with --everything or --plocate, described as lightning-fast search. The pairing is deliberate, both tools maintain filesystem indexes that would otherwise go unused by a query tool, and fselect becomes their query language. Ignore file support, honoring .gitignore, .hgignore and .dockerignore, exists but is marked experimental, worth knowing before trusting results inside repositories. Interactive mode, fselect -i, gives a readline driven shell for iterating on queries, built on rustyline with the directories crate for its history location, and both are default features alongside git integration, user ownership columns and update notifications.

Ten install channels and a test-runner image

Installation coverage is unusually thorough, cargo install fselect from source, deb and rpm packages on the releases page, two AUR packages maintained by different contributors, nixpkgs packaging, static musl and glibc binaries for x86_64 and aarch64 Linux, a Windows zip, winget, Chocolatey and Scoop on Windows, gzipped macOS binaries for Intel and Apple Silicon, Homebrew and MacPorts, a channel for nearly every audience. Output formats include CSV, JSON and others through the into clause, and a bash completion script ships in the repository. The Dockerfile is a one liner in spirit, rust latest, cargo install locked, and a default command that runs cargo test, an image built to run the test suite rather than to serve the tool. Releases are steady, 0.10.1 in May, 0.10.2 in June and 0.10.3 on 2026-09-05, the same day as the last push, under the dual MIT and Apache-2.0 licensing Rust projects standardize on.

Editorial conclusion

Use fselect when a file hunt has structure, size ranges, metadata predicates, comparisons across directories, aggregations, that predicate chains in find turn unreadable, since the SQL shape keeps them composable and the metadata coverage is far beyond stat. Keep find and ls for the simple cases, the project itself says it does not tend to fully replace them. Before relying on it, read the usage guide's query grammar for the relaxed corners, note that ignore file support is experimental, and if speed matters on huge trees, build with the everything or plocate feature and confirm the matching index exists on the machine, since index-backed search is only as current as the index behind it.

Frequently asked questions

Official sources

1. jhspetersson/fselect on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases