Maybe you should take a look at fselect, that uses SQL dialect for search queries and supports archives (and much more).

https://github.com/jhspetersson/fselect

tbh, I probably wouldn't have written zfind if I had known about this.

fselect still takes the SQL analogy a bit too far for my taste, still cool though :)

Oh and fselect doesn't do tar.

Also tbh, I strongly prefer your query strategy; it doesn’t require I remember an entire grammar, just a few keywords (‘size’ etc) which are probably at the top of your man page. If a replacement for ‘find’ - which annoys me because I have to dig through the man page anytime I do something nontrivial- forces me to dig through their man page to remember a grammar … you catch my drift. Hope you keep keepin on, and thanks.

This looks awesome, I'm gonna play with this today. Thanks for the rec

If you're trying to replace find, please add something equivalent to find's -print0/-ls to feed it's output into xargs. Otherwise it may not work correctly on unusually named files (not that I've tried it yet).

EDIT: seems to be a similar issue with fselect: https://github.com/jhspetersson/fselect/issues/150

Thanks, good point. I'll make sure to add it.

Neat, at first glance the -w option is almost required… this often means it should be bare args, skipping the option syntax. Maybe relax the mandatory quotes too?

    zfind —-csv size gt 20k and name = foo

The bare args are for the path(s) to search.

zfind -w 'size>20k and name="foo"'

I could consider having the first arg reserved for -w

zfind 'size>20k and name="foo"'

but I much prefer the quotes and being allowed to write > instead of gt.

The path is rarely useful and almost always ".". Might want that as an option, "-p /etc"

I used gt as bare word but doesn't preclude having escaped or quoted symbols as well, e.g.:

    size \> 20k 
    'size > 20k'

> The path is rarely useful and almost always "."

What, no.

I will easily type out `find` invocations dozens/hundreds of time per workday over years and the fact that it requires the path as the first argument and won't accept it as last _still_ trips me up and is my one major gripe.

Sounds like you misunderstood the comment? You could put -p foo at the end.

Unfortunately that's not the same due to find args being order-significant.

It's the difference between only searching the desired dirs, versus recursing through your entire filesystem (well, cwd) and then filter results based on path.

Having to go into the middle of the line to change the most commonly changed parameter is bad ergonomics when rerunning stuff from history with small variations often. Especially when basically only find is the special kid and everyone else is happy with it at the end. And it's not like it's ambiguous: find will just throw an error and tell you what you should have typed (as opposed to any other misorder, which it will still run, just not the way you might expect; see above re -path)

Having to cd first would be even worse.

This is a modern reinterpretation of the concept, not the tool. No reason an option can't go at the end unless you're determined to copy limits from the past. If so, maybe just use find and save yourself the trouble.

Interspersed/intermixed options have been around for quite a while, though not certain they made their way to golang. If not, the program could handle argument processing itself.

This reminds me how much I love tcpdump it is one of the best domain specific languages I have seen on the command line. Having "and port 53" do the right thing is beautiful also without quotes.

What's your favorite primer on tcpdump syntax? I don't know why, but I always have to go back to my notes for anything even mildly complex.

great added this to my $PATH

i make lots of custom bash file editing and this is gonna help mein the futuré

also does 7zip and rar now