[vsl]

*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.

[coldpie]

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.

[oguz-ismail]

> 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.

[burntsushi]

> fd does that for English only.

That's false. Counter-example:

    $ touch 'Δ'
    $ fd δ
    Δ

Your Turkish example doesn't work with `fd` because `fd` doesn't support specific locales or locale specific tailoring for case insensitive matching. It only supports what Unicode calls "simple case folding." It works for things far beyond English, as demonstrated above, but definitely misses some cases specific to particular locales.

[jandrese]

Casefolding is a minefield once you extend past English. It is completely unsurprising to find problems with it in other languages.

[burntsushi]

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.

[1]: https://unicode.org/reports/tr18/#Tailored_Support