100% POSIX and glibc compatible globbing library for C, Zig, and Rust that is faster and supports all the modern globbing formats (more than libc and rust glob crate)
It supports all the formats like * and {a,b} expansion as long as have a very efficient syscall and SIMD optimization for faster processing
That's one of the reasons I built zlob. It literally has an endpoint to do this but if you are talking about glibc there are 2 options
1. fnmatch function which is not ideal because it doesn't take into account all the path specific optimizations and does not support BRACE
2. ALTDIRFUNC flag for globbing let you simulate file system which absolutely sucks
in zlob you can simply call zlob_match_paths(<pattern>, <list>, flags, ptr)
where list would be either c string or rust/zig like slices
,, 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?
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.
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''.
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)
What sibling comment says. Bash does suppress nonexistent products when the pattern includes a glob metacharacter and `shopt -s nullglob' is in effect, but I didn't see a flag or anything to achieve that in the project README.
100% POSIX and glibc compatible globbing library for C, Zig, and Rust that is faster and supports all the modern globbing formats (more than libc and rust glob crate)
It supports all the formats like * and {a,b} expansion as long as have a very efficient syscall and SIMD optimization for faster processing
Thanks for sharing. Just curious, is there any way to perform globbing over a list of path-like strings instead of only directly on the filesystem?
In case someone doesn't know, the standard function for that is called fnmatch:
https://man7.org/linux/man-pages/man3/fnmatch.3.html
That's one of the reasons I built zlob. It literally has an endpoint to do this but if you are talking about glibc there are 2 options
1. fnmatch function which is not ideal because it doesn't take into account all the path specific optimizations and does not support BRACE 2. ALTDIRFUNC flag for globbing let you simulate file system which absolutely sucks
in zlob you can simply call zlob_match_paths(<pattern>, <list>, flags, ptr)
where list would be either c string or rust/zig like slices
,, 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!
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.
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''.
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)
Since when `{...}' syntax is a glob pattern? What does `{a,b}/c' produce when there is no directory named `a'?
Since glibc (better to say csh) implemented it. https://man7.org/linux/man-pages/man3/glob.3.html search for GLOB_BRACE
Globbing is a matching library. It just means match a/c or b/c if they exist. You should get an iterator of somewhere between zero and two elements.
would it not just produce 'b/c'? assuming 'b/c' is an existent file path
what else could you justify it doing?
The behavior of bash would be to produce "a/c" and "b/c", even if both files don't exist
> The behavior of bash would be to produce "a/c" and "b/c", even if both files don't exist
In bash patterns like {a,b} aren't glob-expansion expansions, they're string operations, and those resolve before glob expansions.
You can confirm this with: ls /{nope,tmp}
zsh too
What sibling comment says. Bash does suppress nonexistent products when the pattern includes a glob metacharacter and `shopt -s nullglob' is in effect, but I didn't see a flag or anything to achieve that in the project README.
Nice licence, I would've probably used this a few years ago on a project had I known it existed.
Was this vibe coded? Readme has typos and somehow reads "fast and loose".
I thought typos was a signifier for human-created these days, because an LLM is unlikely to land on something that is not a word.
I agree with you. I'll speculate no further.