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 zfind —-csv size gt 20k and name = foozfind -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.
I used gt as bare word but doesn't preclude having escaped or quoted symbols as well, e.g.:
size \> 20k
'size > 20k'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.
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.
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.