[Toybox] Towards find cleanup

[Rob Landley]

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