On Wednesday, March 30, 2011 9:07:45 AM UTC-7, Michael Snoyman wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>Thanks to you (and everyone else) for the informative responses. For<br>now, I've simply hard-coded in UTF-8 encoding for all non-Windows<br>systems. I'm not sure how this will play with OSes besides Windows and<br>Linux (especially Mac), but it's a good stop-gap measure.</p><p></p></blockquote><div>Linux, OSX, and (probably?) FreeBSD use UTF8. It's *possible* for a Linux file path to contain arbitrary bytes, but every application I've ever seen just gives up and writes [[invalid character]] symbols when confronted with such.<br><br>OSX's chief weirdness is that its GUI programs swap ':' and '/' when displaying filenames. So the file "hello:world.txt" will show up as "hello/world.txt" in Finder. It also performs Unicode normalization on your filenames, which is mostly harmless but can have unexpected results on unicode-naïve applications like rsync.<em></em> I don't know how its normalization interacts with invalid file paths, or whether it even allows such paths to be written.<br><br>Window's weirdness is its multi-root filesystem, and also that it distinguishes between absolute and non-relative paths. The Windows path "/foo.txt" is *not* absolute and *not* relative. I've never been able to figure out how Windows does Unicode; it seems to have a half-dozen APIs for it, all subtly different, and not a single damn one displays anything but "???????.txt" when I download anything east-Asian.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><p>I *do* think it would be incredibly useful to provide alternatives to<br>all the standard operations on FilePath which used opaque datatypes<br>and properly handles filename encoding. I noticed John Millikin's<br>system-filepath package[1]. Do people have experience with it? It<br>seems that adding a few functions like getDirectoryContents, plus<br>adding a version of toString which performs some character decoding,<br>would get us pretty far.</p></blockquote>system-filepath was my frustration with the somewhat bizarre behavior of some functions in "filepath"; I designed it to match the Python os.path API pretty closely. I don't think it has any client code outside of my ~/bin , so changing its API radically shouldn't cause any drama.<br><br>I'd prefer filesystem manipulation functions be put in a separate library (perhaps "system-directory"?), to match the current filepath/directory split.<br><br>If it's to contain encoding-aware functions, I think they should be Text-only. The existing String-based are just to interact with legacy functions in System.IO, and should be either renamed to "toChar8/fromChar8" or removed entirely. My vote to the second -- if someone needs Char8 strings, they can convert from the ByteString version explicitly.<br><br>--------------------------------------<br>-- | Try to decode a FilePath to Text, using the current locale encoding. If<br>-- the filepath is invalid in the current locale, it is decoded as ASCII and<br>-- any non-ASCII bytes are replaced with a placeholder.<br>--<br>-- The returned text is useful only for display to the user. It might not be<br>-- possible to convert back to the same or any 'FilePath'.<br>toText :: FilePath -&gt; Text<br><br>-- | Try to encode Text to a FilePath, using the current locale encoding. If<br>-- the text cannot be represented in the current locale, returns 'Nothing'.<br>fromText :: Text -&gt; Maybe FilePath<br>--------------------------------------<br>