[xiphias2]

,, Why? Because glob() implemented by glibc sucks. It is very outdated and slow.''

Isn't this a great opportuninty to improve glibc itself instead? Have you tried contributing back and make all programs that use glibc work faster now that you have a lot of knowledge about the problem space?

Anyways congrats to your project!

[kvuj]

There is probably greater joy in quickly making a tool to solve a problem you face than spending months if not years trying to convince glibc maintainers that your redesign will help a majority of users all the while conforming to their demands.

[xiphias2]

Of course it's more fun to create a new micro-library, that's the main reason for me to respect the people who maintain the old libraries instead of just writing ,,it sucks''.

[neogoose]

I agree though the main problem for me is not the API it's missing functionality of patterns like ./*/*.c. There is a very long running thread in the gnu mailing list where authors do not like this idea.

While I need this because everyone expects it to be available. Another reason is the API for thing like someone else asked here already (match in memory over a list of paths)