Unlike xinstall/install, find is a command that's far more likely to be used in the MacPorts base code than in a Portfile. Making it match the find command-line usage simply makes it more complicated to use, since it doesn't actually match the command-line usage. And I'm not sure why you're arguing against my changes in this context, since your implementation didn't match command-line usage either.

You're right, neither of our implementations was the find(1) counterpart that xinstall is to install(1).  However, you've already renamed your find so I guess this point is somewhat moot and now we simply need to define the feature set of the find procedure.  I hope we're at least on the same page with respect to using that proc predominantly from Portfiles vs from base?

find file src {string match *.o $file} {file delete $file}

Except, of course, that what you just typed wouldn't work. It would find all the object files in the src directory, but not in any of its subdirectories because it wouldn't match any of its subdirectories.

Well, again, you don't need to tell find(1) to traverse subdirs so I wasn't expecting that it needed to be explicit in this case either.   If I just wanted to do file ops within the current directory, I'd use glob and eval. :-)

I think the biggest problem here is you're optimizing for Portfile use case while I'm optimizing for MacPorts base code use case. Why am I doing this? Because I know right off the bat two places where this is useful in base code - the delete proc in portutil and pippings new +universal build stuff for ports like openssl that need two single-architecture builds.

Well, perhaps now that we've bifurcated, we can satisfy the needs of both.   So, shall we start defining the behavior of find before doing the implementation and avoid the risk of getting into unnecessary arguments post-facto? :-)

Incidentally, I hope you've also twigged to the fact that modifying someone else's code in an OSS project is almost always bound to lead to a more heated discussion than if you'd actually discussed your proposed changes in advance and allowed for public comment before changing anything.  MacPorts isn't unique in this way - if you'd gone and hacked on one of *BSD or Linux's device drivers and committed the changes without saying anything first, well, let's just say this conversation would still be burning hot with lots of folks piling on.  MacPorts is small enough that this doesn't really happen yet, but the principles remain the same and once MP gets bigger, you'll see an increasing need for discussion in advance of "svn commit".

- Jordan