Contributing into the discussion about find.
Most of its selectors are implemented by stest(1); commonly useful
ones that I can think of are -user and -group. However:
1) ostracize me, but I like find "one dash, long option" style way
more than stest "a thousand of letters a-la test". I understand the
test(1) legacy here, I just say that it wouldn't be very pleasant to
consult with manual each time I'm trying to write a command.
2) there is no way to express intersection, union and negation of a
test. They are mostly irrelevant for test(1), but here we ought to
have at least disjunction, because making temporary lists and merging
them with sort -u or comm(1) is unpleasant to say the least. (Also,
slow). Theoretically speaking, every logical expression can be
represented in conjunctive normal form, so providing support for
negation and union and using multiple commands & pipes as intersection
("| stest test1 | stest test2") should be enough, but in some cases,
unpleasant too.
3) we need a program that can print a directory tree well, with
-mindepth, -maxdepth, and sorted/unsorted options.
4) we need some standard way to separate file names in a stream.
Basically, ^_AT_ is our only refuge, because path can contain any other
character. But maybe newline is good enough?
5) we need a program that can take input and convert into a
commandline. So, xargs (but of course without space-separation
quotation nonsense. Not once nor twice had I written the glorious "tr
'\n' '\0' | xargs -0" to turn it off). I suppose most of POSIX options
are worth keeping.
So, the former "find" command would be like
ptree -maxdepth 2 | ftest "( perm 111 || newer ./reference ) && user
root" | xargs rm
I feel that going the awk way (e. g. inventing the mini-language and
passing expression as one string) is better than find way, with -a and
-o and escaped parens.
--
Best regards, Alexander.
Received on Sat Oct 19 2013 - 03:00:44 CEST