wolfgang.thaller at gmx.net
Thu Mar 15 19:15:11 EDT 2007
On 15-Mar-07, at 7:18 PM, Neil Mitchell wrote:
>> Alas, this is no solution at all. The point is: Currently there is
>> no explicit
>> conversion FilePath <-> String, although this is really needed.
>> Users e.g.
>> enter FilePaths somehow through a GUI, on the command line, in a
>> configuration file etc., so you often start with a String.
> Surely both FilePath's and command line arguments are sufficiently
> string like that a reasonable interpretation of them is String? We
> don't want to provide an interface to Unix, we want to provide a
> proper abstraction over the underlying details.
Indeed, paths and command-line arguments are becoming very string-
like on Unix systems, too.
On Mac OS X, the locale for file names is pretty much hardcoded to
UTF-8. Mac OS X's native file system stores file names in UTF-16, but
the POSIX layer sees it as UTF-8.
For the last several years, all Linux distros I have used myself had
all their filenames stored in UTF-8. And even before that, there was
usually a single filename encoding used for the entire system. I have
also heard that Java, Qt and GTK all can't handle file names that are
invalid in the current system-wide encoding. For all intents and
purposes, filenames that don't match my system encoding on my linux
box are unusable. I only need to be able to access them from 'mv' and
'rm', and if 'fsck' automatically renamed them for me, I'd be even
happier. If people want to write Haskell replacements for these basic
tools, they can be expected to use platform-specific lower-level
functions imported from System.Posix.
> It would be a shame if on my Windows box I had to jump through
> artificial hoops because Posix is a bit broken...
Repeat the above statement with s/Windows/Mac OS X/ and again with s/
Windows/Single-User Desktop Linux/.
More information about the Libraries