Path, OsStr, and supporting non-UTF-8 paths/inputs

[quinedot]

@kornel

Even clap hardcoded a String assumption, and you can panic Cargo and almost every Rust tool by providing a non-Unicode path.

Last I checked, Cargo catches this (and exits, but catches this). It used to panic. clap can handle it now... if you ask it to. Default is still to panic. So there has been some improvement... but not nearly so much as I wish. Doubt it will happen so long as OsString has severely limited capabilities though.

@Michael-F-Bryan

Although I find the OsStr versions not overly useful because you need to turn it into a String if you want to use it for anything other than a file name.

You have to carry it around as an OsStr/OsString forever, yeah. And you have to write! it, or if you don't mind printing a mangled version, temporarily make it a &Path so you can .display() it (why doesn't OsStr have this directly?). bstr can help. There's some other libraries that will print escaped versions instead of mangled versions.

@erelde

Though I feel a maintainer is entitled to say "I don't support non UTF-8 paths, please don't use weird bytes in your filenames."

I wouldn't call them weird; EUC is still going strong in SE Asia.

But given the limitations, I don't disagree with that stance either, necessarily, if it makes sense for the application. Arguably it makes sense for Cargo, say, since module names are also UTF8 in Rust. But it does irk me when I see it in a "here's my oxidized cat, you'll never need the original" or whatever.