-
Notifications
You must be signed in to change notification settings - Fork 79
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
glob() should take a Path not str #78
Comments
I'm not sure there is anyone actively working on this crate, and fixing this bug probably requires non-trivial changes. You might consider using |
Oh, sorry about the noise 😅 It showed up in the "GitHub Explore" mailing-list "based on your public repository contributions". Thanks for the pointer. |
globset seems to have the same problem, [edit: and globset doesn't have a dedicated issue tracker] |
No, globset does not suffer from the same problem. globset does require valid UTF-8 for the pattern, but it's matching function can accept any path.
It might some day, but you can just file bugs against ripgrep with globset mentioned in the issue. If you have a use case for specifying a pattern that isn't valid UTF-8, then I would certainly be happy to have a bug for that, but please provide a real example, because it's not actually clear what the intended semantics should be. Also, the focus on "Americans" is completely unnecessary. UTF-8 isn't specific to Americans. |
On a ISO-8859-15 system, I might want to match I might also just want to build a pattern from an existing |
Thanks for the example. I filed an issue and turned your example into code: BurntSushi/ripgrep#1250 |
Paths on UNIX are bytes, not unicode. Using
str
means that all of them can't be represented.In particular, on systems set with a different locale, or when using disks that were created in a different locale, or simply because of some glitch somewhere, files using non-UTF-8 byte sequence can totally exist.
Not only is it not that much of a corner-case, but the standard library already dealt with that by providing the
Path
type.AsRef<Path>
can also be used to allow users to still pass in string slices and string literals.Related to #23 which is not about the interface but a bug in the internals.
The text was updated successfully, but these errors were encountered: