[24079] trunk/base/src/pextlib1.0/find.c

[Kevin Ballard]

The users of the original find command was, well, nobody. The few  
times I considered using it, I shied away as well. Why? Because I  
didn't want to add dependencies on the API when it was, frankly,  
pretty bad. It set a global variable (yes, not even local to the  
calling procedure, but global) called _filename.

I'm also confused as to your complaint about it executing the body  
every time. With your original implementation, it executed the match  
every time, and every time it succeeded (most of the time, as it  
defaulted to "expr 1") it would then execute the body (which  
defaulted to printing the file, though I'm not sure why as any  
practical usage of the command doesn't want to print the result).

The phrase "The fact that many people used find" is pretty strange  
seeing as, to the best of my knowledge, absolutely nobody was using  
the function. I used it for a very brief time, and then I stopped  
because I didn't want to rely on an API that I intended to change.

In any case, the standard usage for something like this is to  
traverse a filesystem and perform some action on each file that  
matches the criteria. The new find command is intended specifically  
for this. It's basically a foreach on a recursive glob. A theoretical  
usage might look as follows:

find src file {
     switch -glob $file {
         .svn -
         CVS  { continue }
         *.o  { file delete $file }
     }
}

This particular example deletes all object files in the src  
directory, skipping the .svn and CVS dirs because it knows it doesn't  
need to recurse into them. Doing the same with the old command would  
be quite bizarre - the match body has to match directories or it  
won't recurse, which means the action body has to also do its own  
matching to make sure it's acting on the object file and not on a  
directory.

BTW, if you're confused, I wrote the usage wrong in that commit  
message - varname comes before the target list. The correct usage is  
documented in the portfile.7 manpage.

Can you please explain why you think this is a regression? I will  
note that I tried to use your find command at one point, and ended up  
having to pour over the source code to figure out how it was intended  
to be used and why it wasn't behaving the way I expected it to.

On Apr 16, 2007, at 4:15 AM, Jordan K. Hubbard wrote:

> On Apr 15, 2007, at 10:44 PM, source_changes at macosforge.org wrote:
>> Rewrite Pextlib find command. Now actually has useful API. Usage  
>> is find ?-depth? ?-ignoreErrors? target ?target ...? varname body.  
>> -depth identical to -d switch to find. -ignoreErrors causes it to  
>> ignore permission/read errors. Does not follow symlinks.
>
> I'm not sure I exactly agree with that statement.   First, the  
> usage statement is a little confusing - can you cite some actually  
> usage examples?
>
> Second, you've forced the execution of the body every time, and  
> that was not the original intention of this API.  The original  
> intention was to have an Expr evaluated as a predicate and ONLY  
> execute the body if the expr matched, allowing you to separate the  
> "work statements" from the "match statements" - now you have to  
> write a conditional into every body instead and it doesn't read as  
> well.  The fact that many people used find with an expr of "1" is  
> besides the point - you could just as easily match against a  
> specific filename regexp, or file type, or whatever.  Just as find 
> (1) has a whole bunch of predicates which precede -exec, so this  
> command was intended to give you one complex predicate (with all  
> the usual boolean operators) and the equivalent of "-exec" in the  
> body.
>
> I'm having a hard time seeing this as anything but a regression, so  
> perhaps you could explain your rewrite to the original author, at  
> least? :-)

-- 
Kevin Ballard
http://kevin.sb.org
eridius at macports.org
http://www.tildesoft.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-changes/attachments/20070416/32b1e173/attachment.html