On 04/10/2013 01:12:40 PM, Tim Bird wrote:
On 04/10/2013 10:41 AM, Felix Janda wrote:
> Hello,
>
> attached is some cleanup of the find toy inspired by Rob's (very
cool)
> mails on how he proceeds when cleaning up toys. (and Isaac's recent
> partial cleanup of xzcat)
>
> The patch contains a commit message.
>
> The cleanup was mainly mechanical and I still don't understand the
toy
> well. (Before and after the cleanup) there seems to be a problem
with
> the rule parsing/interpretation. For example
>
> find . \( -type f -type f \) -o -type d
>
> does not print directories.
Hmmm. I'm not sure that's a legal filter expression. what is
"-type f -type f"? Is there supposed to be an operator (-a or -o)
in there?
We need some good find tests. Right now the best I've got is running
the Aboriginal and Linux From Scratch builds through it (I rememer the
linux kernel build has broken busybox find before, and last I checked
"make clean" still didn't work), but I should also do a close reading
of posix and come up with a scripts/test/find.test
In general, regular find may be a little more liberal interpreting
filter expressions than the find toy. I think that regular find
will often imply an 'and' when no operator is specified. I considered
this for the find toy, but didn't want to gum up the parser with weird
handling. I know that lots of times people do things like string a
bunch
of filters together without 'and's, like so:
find . -type f -name "*.o" -mtime -20
These types of sequential and's ought to be supported. But allowing
for unspecified 'and's in weird places in a complex parse expression
seems like overkill for a toy.
We have to support what people actually use. Plans never survive
contact with the enemy, standards and initial designs seldom survive
contact with real world datasets. :)
There used to be debug code in the find toy to dump the expression
tree,
but Rob removed it. (I'm not complaining, I think the code should
have
been removed eventually). To debug this, please use a debugger to
make
sure the filter expression tree matches what you think it should be
based
on the command line, then verify that the actually filtering
(expression
evaluation) proceeds as desired.
Rule of thumb: other people's debugging printfs are seldom as useful as
your own debugging printfs. Because you know what your output _means_,
and if you can't annotate the code to dump what you need you haven't
read enough of it yet.
Rob
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
