Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zlob.h 100% POSIX and glibc compatible globbing lib that is faste and better

github.com

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Zlob.h 100% POSIX and glibc compatible globbing lib that is faste and better

#11

Post by jzwinck »

gary_0 wrote: post #3
neogoose wrote: post #2

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

Re: Zlob.h 100% POSIX and glibc compatible globbing lib that is faste and better

#12

Post by frizlab »

thayne wrote: post #6
hidroto wrote: post #5

Earlier quoted context omitted.

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

zsh too

Re: Zlob.h 100% POSIX and glibc compatible globbing lib that is faste and better

#13

Post by Spivak »

oguz-ismail2 wrote: post #4

Since when `{...}' syntax is a glob pattern? What does `{a,b}/c' produce when there is no directory named `a'?

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.

Re: Zlob.h 100% POSIX and glibc compatible globbing lib that is faste and better

#14

Post by sgbeal »

thayne wrote: post #6
hidroto wrote: post #5

Earlier quoted context omitted.

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}

Re: Zlob.h 100% POSIX and glibc compatible globbing lib that is faste and better

#15

Post by [deleted] »

oguz-ismail2 wrote: post #7
hidroto wrote: post #5

Earlier quoted context omitted.

would it not just produce 'b/c'? assuming 'b/c' is an existent file path what else could you justify it doing?

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.

[deleted]

Re: Zlob.h 100% POSIX and glibc compatible globbing lib that is faste and better

#16

Post by 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!

Re: Zlob.h 100% POSIX and glibc compatible globbing lib that is faste and better

#17

Post by kvuj »

xiphias2 wrote: post #16

,, 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.

Re: Zlob.h 100% POSIX and glibc compatible globbing lib that is faste and better

#18

Post by xiphias2 »

kvuj wrote: post #17
xiphias2 wrote: post #16

,, 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''.

Re: Zlob.h 100% POSIX and glibc compatible globbing lib that is faste and better

#19

Post by neogoose »

gary_0 wrote: post #3
neogoose wrote: post #2

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?

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(, , flags, ptr)

where list would be either c string or rust/zig like slices

Re: Zlob.h 100% POSIX and glibc compatible globbing lib that is faste and better

#20

Post by neogoose »

xiphias2 wrote: post #16

,, 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!

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)

Post reply on HN