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@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@macports.org http://www.tildesoft.com