Repository navigation
Recursive globs fail too early on partial path match #14934
Description
What version of Bun is running?
1.1.31+e448c4cc3
What platform is your computer?
Linux 6.11.0-400.asahi.fc40.aarch64+16k aarch64 unknown
What steps can reproduce the bug?
console.log(new Bun.Glob(`**/*abc*`).match(`a/abc`))
console.log(new Bun.Glob(`**/*abc*`).match(`z/abc`))What is the expected behavior?
true
true
What do you see instead?
false
true
Additional information
I'm pretty sure this is because the glob code sees the a and tries the parse the full abc, then bails out early when that fails?
Activity
refi64 commentedon Nov 1, 2024
In
glob_ascii.zig, we have:bun/src/glob_ascii.zig
Lines 401 to 403 in 6933208
I...don't think this is correct? In
a/abc, it "locks in" at the firsta, which makes no sense. Does this maybe need to maintain a stack or similar?Jarred-Sumner commentedon Nov 1, 2024
@zackradisic wdyt?
Jarred-Sumner commentedon Nov 2, 2024
@dylan-conway spent some time investigating. This bug is present in both the Zig and Rust library our glob implementation was partially based on
dylan-conway commentedon Nov 2, 2024
Likely the same bug: devongovett/glob-match#9
**/*name*to any file paths #16878 as a duplicate of this issue