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 different things?

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 system purposes.

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 -J path.

Reply via email to