Right - given that filepath is a path manipulation library, not tied to any particular filesystem, and indeed one in which arbitrary imaginary paths can be manipulated, any normalization under consideration can only be that which is independent of global system state. What does happen in practice is that people compare paths without taking into account that a user might have written "a//b" where you have an entry for say "a/b" in your database. Normalization avoids these errors, but I can see the appeal of not interpreting the byte sequences at all, and the kind of normalization that can be done without appeal to global system state ends up being smaller than expected anyways.
So +1 for the proposal as-is. On 28 June 2015 at 23:09, Neil Mitchell <[email protected]> wrote: > When talking about "filepath" specifically as something you prod at a > specific file system, you can think about normalisation, provided you > have a specific drive in mind. However, if you're going to do that, on > Linux it's almost better to use an inode number. I have two specific > problems with normalisation: > > * You might hope for the property that after normalisation equality of > file locations is equality of FilePath values. That's not true. On > Linux you have symlinks. On Windows you have case sensitivity, which > is a property of the filesystem, not the OS. You might be able to > assume a == b ==> same a b, but you can never assume a /= b ==> not > (same a b), so normalisation doesn't really change the guarantee. > > * I believe some Emacs user once told me that a//b is not the same as > a/b in some circumstances. On Windows, there are lots of programs that > require / or \. Some programs require ./foo and some require foo. The > exact path you pass to some programs gets baked into their output, > which is visible in the final release. While paths might be equal for > the purpose of asking a file system to get some bytes back, they are > often different for the other things people want to do with them, like > pass them to other programs that use the paths. > > > > On Sun, Jun 28, 2015 at 3:47 PM, Boespflug, Mathieu <[email protected]> wrote: >> On 28 June 2015 at 16:34, Sven Panne <[email protected]> wrote: >>> 2015-06-28 12:03 GMT+02:00 Boespflug, Mathieu <[email protected]>: >>>> >>>> why does the proposal *not* include normalization? [...] >>> >>> >>> I think this is intentional, because otherwise we are in the IO monad for >>> basically all operations. What's the normalized representation of >>> "foo/bar/../baz"? >> >> Notice that the kind of normalization I'm talking about, specified in >> the link I provided, does not include this kind of normalization. >> Because it requires the IO monad to perform correctly, and only on >> real paths. >> >> Here is the link again: >> >> https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise >> >> Full canonicalization of paths, stripping out redundant ".." and >> whatnot, should certainly be done in a separate function, in IO. >> _______________________________________________ >> Libraries mailing list >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
