"one" </> "/two" == "/two" needs explanation

[wereHamster]

Nothing in the documentation indicates that behavior: http://hackage.haskell.org/package/filepath-1.4.0.0/docs/System-FilePath-Posix.html#v:-60--47--62-

[ndmitchell]

So the docs for </> point at combine, but I agree a few more examples at </> are wise. Unfortunately the docs for combine have been misrendered, which makes it harder to see the examples as well. That's very unfortunately, I should fix both issues.

[wereHamster]

It would be nice if the package exposed a function which combines the two paths as "one/two". There is such a function internally (combineAlways), but it is not exported. I use joinDrive which is a synonym for combineAlways. But that workaround makes my code more complicated to understand.

[ndmitchell]

What are you using that function for? Any examples? I'm not totally against it, but I'd like to understand in what circumstances it should be recommended.

[wereHamster]

I have a function which may return an absolute URL path (eg. /assets/app-1234.js). I need to take that path and write the file contents to the filesystem under a base path (eg. dist/). This base path may or may not be absolute and may or may not have a trailing slash.

So, in Haskell language:

dump :: FilePath -> FilePath -> ByteString -> IO ()
dump basePath assetPath body = writeFile (basePath </> assetPath) body

main = do
    dump "./dist/" "/assets/app-1234.js" "..."

I would rather have two functions which are clearly documented than one which tries to guess what my intentions are.

[rwbarton]

Without having examined all the examples for combine closely, I think it has a single clear purpose, though the documentation doesn't really state it. That purpose is:

If path1 names a directory B relative to a directory A, and path2 names an object (file or directory) C relative to directory B, then combine path1 path2 names the object C relative to directory A. Or in other words, to use a weird shell/Haskell hybrid, (cd path1 && cat path2) should cat the same file as cat $(combine path1 path2).

@wereHamster's operation I think is best viewed as splitting the absolute path /assets/app-1234.js into a relative path assets/app-1234.js on top of the absolute path /, then combining that relative path with the bast path ./dist/. In general this operation is useful even when splitting off an absolute path other than /; for example you might have your web server configured to serve /assets/ from a directory that is not named assets, and need to split off /assets/. In general you might want an equivalent to Data.List's stripPrefix for this purpose, though I guess makeRelative and isRelative handle this pretty well. In the case of / you can obviously write it in a number of simple ways depending on how you want to handle the input not actually being an absolute pathname.

[thomie]

Maybe we should rewrite combineAlways a bit, and enforce the following rules:

combineAlways x y == x </> (dropDrive y)
Valid x y => isValid (combineAlways x y)

It would prevent current invalid results such as:

combineAlways "C:/" "D:/foo" == "C:/D:/foo"

@wereHamster: please note that joinDrive is only a synonym for combineAlways since filepath-1.4.0.

From the 1.4 changelog:

• Semantic change: joinDrive /foo bar now returns /foo/bar, instead of /foobar

Edit: a consumer of this new version of combineAlways would be Cabal, in the file Cabal/Distribution/Simple/InstallDirs.hs, when installing a library with the --prefix configure option:

CopyTo destdir -> fmap ((destdir </>) . dropDrive)

[ndmitchell]

I've clarified a lot, added the intuition from @rwbarton (in Haskell form), put all the docs under </> and included the example that spawned this bug report. I would recommend that if you want to splice URL's in this way you do:

 basePath </> dropWhile (== '/') assetPath

I don't think exposing combineAlways is a good idea - it's very much an internal detail, and one that I'm not convinced will remain consistent forever. Alternatively, define your own:

x +/+ y = x ++ "/" ++ y

This is a lexical operation, rather than a filepath one.

[ndmitchell]

My inclination is to close this ticket now the docs are fixed - anyone still think it would be good to have "something else", and if so, what that something else should do (not in terms of code, more the idea behind it).

[rwbarton]

I think the new comment might be a bit easier to read if you swap the two Haskell bits; then it reads more like a definition of </>, which is what you are documenting. And yes I see I wrote it the "wrong way" originally :)

Aside from that, I agree with closing this ticket.