On Wed, Jul 09, 2003 at 10:02:16PM +1000, Donovan Baarda wrote: > Why the name "wildmatch"?
The code is based on Rich Salz's wildmat.c, but it has been extended a little by me, so I re-named it wildmatch.c (mainly because I reordered the text/pattern args from the wildmat() order to the fnmatch() order). > I have used the name "efnmatch" (extended fnmatch) for it in my Python > implementations. Since the code doesn't try to do some of the fnmatch-style things (like having different flag-specified matching behaviors), calling it efnmatch doesn't seem like the right choice to me. > How did you implement it (I know, I should just look in CVS, but while I'm > typing...)? Does it use regexes or a modified implementation of fnmatch? How > does it compare performance-wise with a regex based implementation? It's roughly comparable to an fnmatch implementation I saw -- it reparses the match string for each comparison. The only performance tests I ran did not reveal any significant differences between the Linux fnmatch library and my wildmatch code, but it was not a very extensive test. There is no attempt to use regular expressions to implement exclude handling at the moment. I discussed that option back when deciding what to do, but decided against it for now. I think using cached regex patterns would probably be a faster approach for those that have a massive amount of include/exclude items, but for those with a normal set of excludes, I doubt it would make a difference (since the task is primarily I/O bound) and I didn't want to add a regex dependency. This is certainly something that could be considered to improve things for the future, though, and we'd be free to make the change at any time since such an implementation would not change how the pattern matching appears to the user (since the recent user-visible changes have all been bug-fixes). > I found by implementing efnmatch using regex's, it was painless to add > the ability to use regex's in include/exclude lists. Yeah, that was my primary reason for suggesting a possible regex underpinning. No one seemed very interested in the idea, though, and as you said yourself, the extra flexibility of regular expressions is not all that necessary for filename matching. To me, the most important part of the exclude changes has been to fix defects in how the matching works. Thanks for the feedback! ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
