[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 duncan):

 Replying to [ticket:3307 YitzGale]:
 > Under Unix, file paths are represented as raw bytes in a String.
 > That is not user-friendly, because a String is supposed to be
 > decoded Unicode, and it is conventional in Unix to view those
 > raw bytes as encoded according to the current locale.

 Unfortunately it is not conventional on Unix to interpret file names as
 Unicode, decoded from the current locale. When presenting file names to
 the user in a user interface some decoding is necessary, though there is
 not universal agreement that the locale is the right one. 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).

 Certainly it's the case that FilePath as a Haskell `String` is not
 accurate for Unix paths (though it is for Windows and OSX). Something more
 accurate would be (an adt containing) a pair of the original binary
 filename and a Unicode human readable `String` decoding of it. It needs
 both because the decoding may be lossy. On Windows and OSX the binary part
 would not be needed because they use Unicode natively.

 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).

 I would argue the solution is to move `FilePath` to being opaque, rather
 than towards it being properly interpreted as a Haskell Unicode `String`.

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