Neil Mitchell wrote:
I have also added a canonicalPath function, support for spotting
file\con as invalid and fixing it, support for \\?\ paths (if you
don't know what they are, don't look it up, they are quite painful!)
and a few very obscure corner cases which broke some of the
properties.
I haven't been following this discussion very closely, but this caught my eye.
Has anyone pointed out yet that eliminating ".." in a FilePath isn't valid in
the presence of symbolic links? I vaguely recall that this is why Krasimir's
System.FilePath library doesn't include normalisation. Normalisation that just
changes separators, removes redundant separators and removes "." components is
probably ok.
I don't really see the point of fullPathWith. Isn't it just combine?
I think shortPath is on dodgy ground, given the difficulty with normalising
FilePaths, and the fact that paths are not unique in the presence of symlinks.
The temporary file stuff is wrong - see System.IO.openTemporaryFile. The only
way to reliably create a temporary file is to open it at the same time,
otherwise there's a race condition.
I have some other issues with naming, and the fact that the library mixes IO and
non-IO functions. We should avoid referring to $PATH as the "path", since we
already have FilePath. eg. spiltPath and getPath are talking about two very
different things. Where you use the term Filename, I think it should probably
be FilePath. I think we should consistently use a single term, preferably FilePath.
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
