Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Single wildcard tree does never matches #54

Open
rnza0u opened this issue Jan 8, 2024 · 2 comments
Open

Single wildcard tree does never matches #54

rnza0u opened this issue Jan 8, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@rnza0u
Copy link

rnza0u commented Jan 8, 2024

Hello,

I might have noticed a bug.

It is stated in the documentation that "If a glob expression consists solely of a tree wildcard, then it matches any and all paths and the complete contents of any and all directory trees, including the root".

I have the following file structure in /tmp/files:

├── dir1
 |   ├── file.txt
├── dir2
 |   ├── file.txt
├── dir3
 |   ├── file.txt

with the following Rust code:

fn main() {
    let paths = wax::Glob::new("**").unwrap()
        .walk(std::path::Path::new("/tmp/files"))
        .not::<[&str; 0]>([]).unwrap()
        .map(|entry| entry.unwrap().path().to_owned())
        .collect::<Vec<_>>();

    println!("{:?}", paths);
}

The output is:

[]

when i remove the negation:

fn main() {
    let paths = wax::Glob::new("**").unwrap()
        .walk(std::path::Path::new("/tmp/files"))
        .map(|entry| entry.unwrap().path().to_owned())
        .collect::<Vec<_>>();

    println!("{:?}", paths);
}

it works:

["/tmp/files", "/tmp/files/dir3", "/tmp/files/dir3/file.txt", "/tmp/files/dir2", "/tmp/files/dir2/file.txt", "/tmp/files/dir1", "/tmp/files/dir1/file.txt"]

Did i miss anything ?

@olson-sean-k olson-sean-k added the bug Something isn't working label Jan 9, 2024
@olson-sean-k
Copy link
Owner

Thanks for the report! Yes, this is definitely a bug! Your first example should indeed yield the entire contents of the directory.

When given an empty collection, not constructs a bogus Any token. This particular API has already been fixed in 76afaa1. However, there isn't yet a test for this and only not has been fixed: this can still happen via the any function in the crate root. To be sure, I just tried a test very similar to this one where the collection is empty and confirmed the correct behavior.

I'll leave this issue open until I land an appropriate test and change all of the concerned APIs such that they don't construct garbage from empty collections.

@rnza0u
Copy link
Author

rnza0u commented Jan 12, 2024

Yes, i read the code and i came to the same conclusion.

The exhaustive and nonexhaustive generated regexes in the WalkNegation were both set to something like this if i remember correctly: ^()$

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants