`include_once` needs to normalize paths before checking if they're the same

[sauclovian-g]

Suppose you have these files:

a/a.saw
b/b.saw
c/c.saw

and suppose both b.saw and c.saw do include_once "../a/a.saw", and c.saw also includes b.saw.

Then from the perspective of c.saw the path of a.saw is ../a/a.saw, but from the perspective of b.saw the path is ../b/../a/a.saw, because we try to make includes relative to where they're included from. But include_once just looks at the path strings, and they're different, so this doesn't work as intended.

This does, however, seem like a reasonable thing to do and to want include_once to work for, so I guess we do need it to normalize paths for comparison... much as normalizing paths is annoying and generally wrong. (That or we could check the system-level file identity... but I'm not sure how you do that from Haskell or whether it's workable in Windows.)

@qsctr

[RyanGlScott]

I agree that normalizing paths in the general case is fraught with peril, and this would likely never catch 100% of the tricky corner cases one could come with. Still, I think that we could at least make an effort to turn relative paths into absolute paths (i.e., using System.Directory.makeAbsolute) without needing to go into more tricky parts of normalization like following symlinks (i.e., using System.Directory.canonicalizePath).

[sauclovian-g]

I think it's better to expand symlinks; otherwise you get weird behavior in the presence of symlinks.

[RyanGlScott]

We certainly could use canonicalizePath to try to expand symlinks, but it does mean that include_once's behavior would rely on the quirks of canonicalizePath's implementation, making it harder to specify what does and does not work.

[sauclovian-g]

It looks like it does in fact have a bunch of quirks (rather than just calling out to realpath(3) in libc, whose behavior is at least well specified) ... however, looking at what makeAbsolute actually does, it won't help at all: all it does is graft the CWD onto the front, so in the example above we'll get the paths /some/where/c/../a/a.saw and /some/where/c/../b/../a/a.saw and we've reduced it to the previously unsolved problem.

Simplifying c/../a to just a, which is what I expect you were intending to suggest, comes confusingly unstuck if c is a symlink, and so I don't think that's a good idea even if there were a readily accessible way to do it.

[RyanGlScott]

Ouch, I didn't realize that makeAbsolute doesn't normalize ... I agree that that makes it an unworkable solution in this setting.

rather than just calling out to realpath(3) in libc, whose behavior is at least well specified

To be clear, canonicalizePath is implemented in terms of realpath(3) on operating systems that support it.

[sauclovian-g]

It doesn't appear to be from following the source links Hoogle found. However, that's immaterial; it's what we've got...