Skip to content
New issue

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

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

Already on GitHub? # to your account

Allow the use of ^ for negation in addition to !? #116

Open
ackerleytng opened this issue Jul 12, 2022 · 2 comments · May be fixed by #141
Open

Allow the use of ^ for negation in addition to !? #116

ackerleytng opened this issue Jul 12, 2022 · 2 comments · May be fixed by #141

Comments

@ackerleytng
Copy link

Would you consider allowing the use of ^ for negation in addition to !?

gnu coreutils supports the use of ^ in addition to !, based on the behavior of ls and du. I tried finding documentation of this in code, and found this in fnmatch.c

Or perhaps, instead of a direct comparison with '!' at https:/github.com/rust-lang/glob/blob/master/src/lib.rs#L614, can we call a method like is_negation_character? That way, this library can be extended.

@ndmitchell
Copy link

This would also be useful for a project I've been working on, where the incompatibility with Java glob libraries caught us by surprise. I note that @ackerleytng used the workaround of replacing the input string - that would be possible for us too, but it seems like a dangerous thing to do and easy to get wrong.

@squell
Copy link

squell commented Feb 25, 2025

There doesn't seem to be much momentum behind this issue (even though PR #141 stands ready to fix it), so let me try to impress some urgency by stating, from the sudo-rs project point of view it would be really good to have this fixed. We really don't have any alternatives (sure, we could move to libc for fnmatch, or start maintaining a fork of glob for this one feature, but we obviously don't want to do either of those things).

If there is fear of incompatibility when caret is added, can we modify #141 so that the modifications that @tertsdiepraam proposed are hidden behind a feature flag? That would be perfectly acceptable for us.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants