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.

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.

Alternative idea: add a caret_negation (or such) field in the MatchOptions structure.

I've looked into this a bit again. The extra config option sounds good, but is a bit tricky because there are currently no options that influence the parsing of the Pattern and this change would require that. By all means though, feel free to take my branch and create a new PR from it with a config option.