Micah Cowan <[EMAIL PROTECTED]> writes: > I'm wondering whether it might make sense to go back to completely > ignoring the system-provided fnmatch?
One argument against that approach is that it increases code size on systems that do correctly implement fnmatch, i.e. on most modern Unixes that we are targeting. Supporting I18N file names would require modifications to our fnmatch; but on the other hand, we still need it for Windows, so we'd have to make those changes anyway. Providing added value in our fnmatch implementation should go a long way towards preventing complaints of code bloat. > In particular, it would probably resolve the remaining issue with > that one bug you reported about fnmatch() failing on strings whose > encoding didn't match the locale. It would. > Additionally, I've been toying with the idea of adding something > like a "**" to match all characters, including slashes. That would be great. That kind of thing is known to zsh users anyway, and it's a useful feature.
