Back in the 90s I was discussing data management
with a Linux peer, and the topic of db came up,
which one, what advantage, etc, the answer?
"The filesystem is a database, just use that."
Disks got bigger and faster, and data transcends,
files from that era 540MB drive are on my SSD;
keys are still nodes and values are still files.
Today, balancing work and life, I might log NetBSD,
Linux, and Darwin, all on the same day. Even though
I've used a variety of db and interfaces, my primary
tooling remains based on filesystem stores and,
with some reluctance, bash has emerged as the
primary language (pkgsrc makes it ubiquitous),
combined with awk/sed, my needs are met. But any
seasoned admin will recognise the gap, whether
looking for a kitchen recipe, tracing an ip from logs,
or some obscure forensic, a big problem working on
all those OS, and trying to share tooling, is the find cmd.
For some years I've been thinking about a wrapper
that would give me one universal interface for my
OS independent tooling but it always turns out more
complicated than I bargained for. Enter LLM and a
vendor gifted credit, earlier this week I prompted ff,
functional find, which is a c-lang program and bash
companion function for validation, or when you cannot
install binaries. The ff.c comes with ff.fn.bash, a man,
makefile, README.md, PLAN.md, and a test script.
The options, primaries, actions and operators are almost
all single character, and the bash function translator
will emit the native OS find command, for extension
A companion program cksh (check stat and hash)
presents inode links hash size mdate name, in a (hex)
Please message me privately if you find any bugs!
I would consider new features if they maintain the
minimalist essential criteria, and I'm happy to share
integration tips, such as translating timestamp formats.
And, thanks John for the FSaaDB hint!
//George
--