dspillett parent
It isn't wrong, 0xff is invalid UTF8. Of course if your locale is not set to UTF8 then that is a potential problem.
*nix filenames are series of bytes, not UTF-8 (or anything else) strings. If a find replacement doesn't accept valid (parts of) filenames as input, it's a bit unfortunate.
If all you want to do is match against a sequence of bytes, sure. But when you want to start providing features like case-insensitivity, matching against file extensions, globbing, etc, then you have to declare what a given byte sequence actually represents, and that requires an encoding.
> when you want to start providing features like case-insensitivity
fd does that for English only. See the III/iii case in my comment; iii capitalizes to İİİ in Turkish, there's no way to have fd respect that.
> fd does that for English only.
That's false. Counter-example:
$ touch 'Δ'
$ fd δ
Δ
Casefolding is a minefield once you extend past English. It is completely unsurprising to find problems with it in other languages.
Yes. I'm the one who implemented the case folding the `fd` uses (via its regex engine).
See: https://github.com/rust-lang/regex/blob/master/UNICODE.md#rl...
And then Unicode itself for more discussion on the topic: https://unicode.org/reports/tr18/#Simple_Loose_Matches
TR18 used to have a Level 3[1] with the kind of locale-specific custom tailoring support found in GNU's implementation of POSIX locales, but it was so fraught that it was retracted completely some years ago.