<br><br><div class="gmail_quote">On Fri, Jun 25, 2010 at 3:15 PM, Brandon S Allbery KF8NH <span dir="ltr"><<a href="mailto:allbery@ece.cmu.edu">allbery@ece.cmu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div><div class="im">On 6/25/10 17:56 , Roman Cheplyaka wrote:<br>
> * Brandon S Allbery KF8NH <<a href="mailto:allbery@ece.cmu.edu">allbery@ece.cmu.edu</a>> [2010-06-25 05:00:08-0400]<br>
</div><div class="im">>> You might want to look at how Python is dealing with this (including the<br>
>> pain involved; best to learn from example).<br>
><br>
> Do you mean the pain when filenames can not be decoded using current<br>
> locale settings and thus the files are not accessible? (The same about<br>
> environment variables.)<br>
<br>
</div>Yes, this.<br>
<div class="im"><br>
> Agreed, it's unpleasant. The other way would be changing [Char] to [Word8]<br>
> or ByteString. But this would a) break all existing programs and b) be<br>
> an OS-specific hack. Crap.<br>
<br>
</div>But it *is* OS-specific, just as Windows' UTF-16 is an OS-specific<br>
mechanism. Unfortunately, there's no good solution in the Unix case aside<br>
from assuming a specific encoding, and the locale is as good as any; but I<br>
think LC_CTYPE is probably the most applicable. This will, however, confuse<br>
everyone else.<br>
<br>
Perhaps best is to look at whether there is any consensus building as to how<br>
to resolve it, and if not use locale but document it as an unstable<br>
interface. Or possibly just leave things as is until consensus develops.<br>
It would be Bad to choose one (say, locale) only to have everyone else go in<br>
a different direction (say, UTF-8 with the application libraries potentially<br>
re-encoding filenames).<br></blockquote><div><br></div><div>In the case of IO you can disable the locale specific encoding/decoding by switching to binary mode. Would a similar API be available when working with filepaths? Darcs, for instance, deals with lots of file paths and has very specific requirements. Losing access to files due to bad encodings, or mistaken encodings, is the sort of thing that would break some people's repositories. So tools like Darcs would probably need a way to disable this sort of automatic encoding/decoding.</div>
<div><br></div><div>Jason</div></div>