[GHC] #3307: System.IO and System.Directory functions not Unicode-aware under Unix

[GHC]

#3307: System.IO and System.Directory functions not Unicode-aware under Unix
-------------------------------+--------------------------------------------
 Reporter:  YitzGale           |          Owner:                  
     Type:  bug                |         Status:  new             
 Priority:  normal             |      Milestone:                  
Component:  libraries/base     |        Version:  6.11            
 Severity:  normal             |     Resolution:                  
 Keywords:  directory unicode  |       Testcase:                  
       Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple
-------------------------------+--------------------------------------------
Comment (by YitzGale):

 Replying to [comment:2 duncan]:
 > Unfortunately it is not conventional on Unix to interpret file
 > names as Unicode, decoded from the current locale.

 AFAIK shells running in all modern vterms and xterms display them
 this way.

 > For example glib uses UTF-8 always, unless you set some special
 > env var to tell it to use the current locale (the latter is considered
 > a compatibility hack that will be phased out).

 Oh really? Is that because we can soon assume that all locales
 are UTF-8?  If so, it makes our work easier, as Ketil pointed out.

 What does Qt do?

 > Something more accurate would be (an adt...

 Yes, a richer type would be a tremendous help. But simonmar has pointed
 out that it would break H98 compatibility, so it doesn't seem to be
 an option.

 > The problem with making `getArgs` and `openFile` return Unicode is it
 > may be impossible to open certain files passed on the command line
 > (those for which the decoding is lossy).

 On the other hand, they are decoded on other platforms. We don't want
 to make it impossible to write platform-independent code for any
 program that reads its args.

 Would that actually happen for users using any normal UI and any normal
 input method? It has always been possible in Unix to create weird file
 names that are very difficult to deal with, but it won't happen in normal
 usage. We can provide a Unix-specific hack for the odd case.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3307#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler