getopts only works with UTF-8 strings, cannot process non-UTF-8 filenames

[samuela]

See samuela/rustybox#32 (comment). This has been a factor in https://github.com/uutils/coreutils migrating from getopts to clap.

[joshuarli]

Same issue in a similar project that was just brought to my attention: google/argh#33

FWIW @samuela, that looks like it's gaining a bit of traction.

[KodrAus]

If it's possible to fix this up without breakage then we'd happily accept a patch to support non-UTF8 args. Otherwise I think we'll probably have to accept the UTF8 requirement as a limitation of getopts.

[197g]

It might be possible but the field Matches::free has type Vec<String> so any additional path argument can't be collected into it without being valid UTF8. It would be necessary to add an additional field with type Vec<OsString> to avoid interface breakage, this is possible as there are private fields, and some opt-in method to populate the field instead of free.

I can provide a patch but want to know if this direction might be potentially accepted before working on it.

[tgross35]

I think it would be better to do this over a breaking version bump and change Matches::free to be a private field of Vec<OsString>. Then we can have separate methods:

fn free(&self) -> Vec<&str>;
fn free_os(&self) -> &[OsString];

free will panic if there are any non-UTF8 options in the internal Vec<OsString>, anyone who needs more fine grained control here can work with free_os directly. The important -> Option<String> methods on Matches can similarly be split into -> Option<&str> (panicking) and -> Option<&OsStr>.

@197g any chance you are interested on working on this still, four years later? :)