Filename handling (was: Remaining bugs in Cabal under Windows)

Graham Klyne GK at
Tue Aug 17 07:43:52 EDT 2004

At 03:16 17/08/04 -0700, Krasimir Angelov wrote:
> > Maybe - although the conventions still differ
> > between Unix and Windows.
> > On Unix, to store per-user data you would use
> > <homedir>/.<app> whereas
> > on Windows you use <homedir>/<app>.  So I think the
> > win32 library should
> > provide access to getAppUserDataDirectory, and the
> > app code still needs
> > to be conditionally compiled.
>Instead we can provide function like:
>getAppUserDataDirectory :: String -> IO FilePath
>where getAppUserDataDirectory "<app>" will return
><homedir>/.<app> or <homedir>\<app>

If we're going this way (which I think is a good thing), I think some more 
generic path query functions could be useful.  When I ported the HaXml+HTTP 
libraries to windows, I needed to be able to find the current directory in 
order to convert a filename into a file: URI, in order to provide uniform 
handling of external entity access and base URI handling.  The logic I used 
is somewhat ad-hoc, and can be seen here:
   (See function "unsafeGetExtEntity".)

There's some related logic I did for Hxml Toolbox to establish a default 
base URI:
   (see function "setDefaultURI".)

All this raises questions about the correct correspondence between file: 
URIs and local filesystem names, which I've raised as a discussion point on 
the mailing list dealing with URI standardization:
with some follow-up in a different thread:


Anyway, I'd like to see the common library functions provide at least 
minimal capabilities to allow multi-platform applications to do the right 
thing when handling filenames.  I'm pretty agnostic about what they 
actually look like, but as an example I've found the Python and/or Java 
libraries to be pretty usable in this respect.


Graham Klyne
For email:

More information about the Libraries mailing list