Bug in -J

[Vladimir Panteleev via Digitalmars-d]

On Saturday, 12 August 2017 at 03:52:25 UTC, Mr. Pib wrote:
> You are making assumptions about me making assumptions... 
> please don't make any more assumptions or we will be in an 
> infinite regression ;/

Sorry, maybe I don't understand the question. Maybe you could 
explain in broader terms the higher-level goal or problem you're 
trying to solve, and maybe we can recommend a better way?

> If are aware, it has nothing to do with absolute paths as the 
> bug should also be exhibited with relative paths. It is a 
> comparison issue of the strings rather than checking to see if 
> they represent the same physical location.
>
> It would be like saying that \x\y is different from \x\..\x\y. 
> Dmd does a blind comparison, I bet, rather than what it should 
> be doing. Obviously \x\y are different strings but they are not 
> different file locations.

Fairly sure we forbid .. out of security considerations.

I don't think this applies to Windows, but on POSIX, depending on 
how .. is interpreted, \x\y x/y actually can mean a different 
file from x/../x/y.

It has taken a lot of consideration and research until we even 
allowed path separators in import paths. For a very long time, 
they were completely forbidden, and a long time after that, they 
were forbidden on Windows (because on Windows things can be more 
complicated due to the various kinds of reparse points and things 
such as short filenames).

> If that is not the case, then a better error message should be 
> given.

Feel free to file a diagnostic enhancement request if you have 
specific suggestions.