On Fri, Mar 16, 2007 at 03:42:10PM +0100, Sven Panne wrote:
On Friday 16 March 2007 15:10, Ian Lynagh wrote:
I'm not clear on exactly what you're proposing: would
getDirectoryContents "." >>= mapM_ removeFile
remove all the files in ".", regardless of what my locale is, my OS is, etc? i.e. would this solve my problem in
http://www.haskell.org/pipermail/libraries/2005-July/004189.html
OK, let's make this a bit more concrete and let's take Mac OS X as an example.
I was really hoping for an answer along the lines of "yes" or "no" :-)
On this platform, peekCString would decode from UTF-8 to Unicode (probably normalizing the Unicode string on the way),
Why normalise it? A lot of the time we'll just be converting back to a filename later, so this sounds like wasted work.
so no information is lost.
Right, the normalising won't lose information as the filesystem requires fully denormalised(or whatever the right word is) filenames AIUI.
OTOH, withCString would encode the Unicode string to UTF-8 (decomposing on the way? Wolfgang?). Both functions are used by getDirectoryContents internally, so this will be "Unicode-enabled" then, too. The main point here is that UTF-8 => Unicode => UTF-8 is lossless,
OK, so I think my answer is "Yes" for MacOS X, which makes sense as both the filenames and strings are unicode.
and the same holds for my proposed change for *nices, too, as long as the local encoding is invertible in this sense. I am not sure if there are encodings in use out there which do not have this property, but even if they are: All e.g. Qt-based programs would share the same problems.
I got lost somewhere along the way here. Linux filenames are (to a first approximation) arbitrary sequences of word8s, unrelated to the "local encoding". So I think the answer to my question is no, getDirectoryContents "." >>= mapM_ removeFile might not remove everything in "." (if, say, my French friend created them and we are using Linux/ext2)? Thanks Ian