On Saturday, 12 August 2017 at 05:42:21 UTC, Mr. Pib wrote:
I'm pretty sure that on no OS does the same location mean
I understand what you mean, but just to clarify on the .. thing:
$ mkdir d d/x d/z
$ ln -s d/z x
$ echo foo > d/z/y
$ echo bar > d/x/y
$ cat x/y
+ cat x/../x/y
I am not talking about strange stuff but simple stuff.
I have code that loads a file at runtime and requires the
absolute path. This is only for debugging purposes. When built
in release, everything is switched over to use imports and
embed the files in the binary. The same path is used for other
things like caching/uniqueID but are never actually read from.
You see this sort of stuff a lot when you open an executable
and see hard coded paths but obviously never used for file
Sounds like you can also work around it using e.g.
enum appRoot = `C:\Temp\`;
string data = readText(appRoot ~ "a.dat");
enum data = import("a.dat");
(and build with -JC:\Temp).
That should now also work if a.dat is in a subdirectory relative
to the -J path.
The files and paths are all the same but import doens't seem to
think so. Adding baseName solves the problem immediately but
that is a hack. import should know that the path is the same as
the one specified by -J. The whole point of -J is to specify
the path for security purposes, right? So why does it matter if
I use path\filename or baseName(filename)? Both point to the
same location and both are consistent with -J, import should
understand that. It is an obvious oversight. But there is an
obvious programmatic difference between the two versions.
Luckily, using baseName does fix the problem so it is not a
huge deal but it is still a bug/issue with import for being
ignorant of what it is actually doing.
Sounds reasonable, the compiler could check if paths start with a