System.FilePath propsal (Was: Cabal feedback notes)
gk at ninebynine.org
Thu Oct 28 10:11:39 EDT 2004
At 06:52 28/10/04 -0700, Krasimir Angelov wrote:
>--- Graham Klyne <gk at ninebynine.org> wrote:
> > > > 2. How does path joining work in this case:
> > > >
> > > > joinPaths C:/root/path/file.ext
> > > > altPath/file2.ext2
> > > >
> > > > i.e. is "file.ext" discarded?
> > >
> > >No. You will get:
> > >
> > >C:/root/path/file.ext/altPath/file2.ext2
> > Hmmm. I can't claim it's wrong, but I'm uneasy
> > about that. It is, for
> > example, different from the way that URI path
> > joining works.
>What do you expect to get? file.ext is a valid
Indeed it is. This is, I believe, an ambiguity with the way
Unix-like-systems present directory and file names, which cannot be
disambiguated without actually consulting the live file system. Windows
has a similar issue. The URI path-joining algorithm would drop the final
"filename" element 'file.ext' (not being terminated by '/'), and give:
>By the way
>joinPaths "c:/dir1/file.ext" "c:/dir2" == "c:/dir2"
>because the second path is absolute.
Good. That's as I'd expect.
> > What about:
> > joinPaths C:/root/path/ altPath/file2.ext2
> > does this give:
> > C:/root/path/altPath/file2.ext2
> > or
> > C:/root/path//altPath/file2.ext2
> > ?
>The first one. "//" is equal to "/", isn't it?
Is it? Is it definitely prohibited to have a zero length path
segment. What is the correct interpretation of this:
(I'm not saying you're wrong, just that the answer isn't entirely clear-cut.)
BTW, whatever the final answer, I think it would be a great idea to have a
unit test module (preferably using HUnit) with all these as test cases. If
only to definitively settle questions from awkard people like me.
More information about the Libraries