On Apr 17, 2007, at 1:24 AM, Jordan K. Hubbard wrote:
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. :-)
Yeah, but I was describing how your example would have behaved with
your implementation, not how it should behave in an ideal world.
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".
Yeah, I know, but the fact of the matter was nobody used find, and I
mean nobody. And the other part is that, in general, it's far more
conducive to stop thinking of code as "my code" or "his code" and to
think of it simply as project code. Sure, you wrote it, but in the
end does that matter? Discussion should be about the merits of the
code, not about ownership.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
[EMAIL PROTECTED]
http://www.tildesoft.com
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
