Tags: -wontfix > Why would unrar even try to do such a thing for an archive filename on > the command line? It would make sense if this had anything to do with the > filenames stored in the archive, but that's not the case.
Because unrar is originally made for Windows. Windows command line programs uses GetCommandline() function and use wide char (wchar_t) strings to get command line options. Unix unrar code uses thin wrapper around startup routines for Windows unrar code to work with multi byte (char) strings. Because Unix uses multi byte strings to get command line options. > The proof for this is that basically every other command has no trouble > with this. If unsure, try to look at how programs such as "cat", "zip" or > "unzip" work, none of which have trouble with this. Unix tools like "cat" and others uses multi byte strings to get command line options. Because "cat" is made for Unix, and no need to convert command line option strings. Anyway, this issue is once forwarded to upstream, but upstream does not want to fix. I have no more ideas about this issue, because I am not an expert of RAR archiver programs. But you can ask your request to upstream by yourself. If upstream releases new version of unrar, I will make new unrar package. -- YOKOTA
