thisExePath resolves symlinks but this isn't mentioned in docs

[dlangBugzillaToGithub]

timothee.cour2 (@timotheecour) reported this on 2016-10-05T01:35:10Z

Transfered from https://issues.dlang.org/show_bug.cgi?id=16595

CC List

• andrei (@andralex)
• doob (@jacob-carlborg)
• timothee.cour2

Description

```
import std.file;
import std.stdio;
void main(){
  writeln(thisExePath);
}
```

```
cd /tmp/
rdmd -oftest main.d
ln -s ./test ./test_foo
./test_foo
/tmp/test
```

expected result:
/tmp/test_foo

Workaround?

[dlangBugzillaToGithub]

doob (@jacob-carlborg) commented on 2016-12-16T08:13:12Z

The implementation of "thisExePath" on macOS calls "realpath". The intention is to get the full path without any extra "/", "." or "..". Removing the call to "realpath" from "thisExePath" resolves in the following behavior:

$ ./d/main
/Users/jacob/development/./d/main

The Linux implementation is using "readlink" to read "/proc/self/exe". This resolves symbolic links as well. I don't know any other way to do it on Linux. So the behavior of macOS and Linux is at least consistent. I don't remember the behavior of the other platforms when it comes to symbolic links.

The workaround would be to implement "thisExePath" yourself. That is, copy-paste the implementation of the existing "thisExePath" and remove the call to "realpath". Perhaps add a call to "asNormalizedPath" if you want to remove any extra "/", "." and ".."

[dlangBugzillaToGithub]

timothee.cour2 commented on 2016-12-16T08:42:00Z

at very least it should be documented; but IMO thisExePath has no business resolving symlinks; and the function that does realpath/readlink should be exposed as a separate function (cross platform), so user could call realPath(thisExePath) if he wants to.

[dlangBugzillaToGithub]

doob (@jacob-carlborg) commented on 2016-12-16T13:28:49Z

(In reply to Timothee Cour from comment #2)
> at very least it should be documented; but IMO thisExePath has no business
> resolving symlinks; 

If I recall correctly, there was no suitable function in Phobos, at the time of the implementation, that cleaned up the path so I resorted to "realpath". As a side effect it also resolves symbolic links. Actually, I don't remember if my intention was to resolve symbolic links or not.

> and the function that does realpath/readlink should be
> exposed as a separate function (cross platform), so user could call
> realPath(thisExePath) if he wants to.

What about platform consistency? Should the function always return "/proc/self/exe" on Linux forcing the user to always call "readlink". Or should they have different behavior?

[dlangBugzillaToGithub]

timothee.cour2 commented on 2016-12-16T19:18:51Z

Good point, I just opened a question to figure out if we can even do that:

http://stackoverflow.com/questions/41190968/how-to-get-path-to-currently-running-executable-without-resolving-symlinks-on

still though, we should have a cross-platform function that implements `realPath` (that  one should be doable); and a function to get thisExePathUnresolved (that is maybe not available on all platforms)

[dlangBugzillaToGithub]

doob (@jacob-carlborg) commented on 2016-12-16T20:51:01Z

(In reply to Timothee Cour from comment #4)
> Good point, I just opened a question to figure out if we can even do that:
> 
> http://stackoverflow.com/questions/41190968/how-to-get-path-to-currently-
> running-executable-without-resolving-symlinks-on
> 
> still though, we should have a cross-platform function that implements
> `realPath` (that  one should be doable); and a function to get
> thisExePathUnresolved (that is maybe not available on all platforms)

I think that is asNormalizedPath [1].

[1] http://dlang.org/phobos/std_path.html#asNormalizedPath

[dlangBugzillaToGithub]

timothee.cour2 commented on 2016-12-16T21:21:53Z

no, as doc says, asNormalizedPath "Does not resolve symbolic links."
realPath would resolve them recursively (just like python realpath)

[dlangBugzillaToGithub]

doob (@jacob-carlborg) commented on 2016-12-16T21:39:21Z

(In reply to Timothee Cour from comment #6)
> no, as doc says, asNormalizedPath "Does not resolve symbolic links."
> realPath would resolve them recursively (just like python realpath)

Yeah, I thought what was what you wanted? There's already readLink [1] to resolve symbolic links.

[1] http://dlang.org/phobos/std_file.html#.readLink

[dlangBugzillaToGithub]

timothee.cour2 commented on 2016-12-17T02:32:15Z

readLink != realpath ; see python realpath: https://docs.python.org/2/library/os.path.html

realpath returns an absolute path, resolving symlinks recursively (among other details); readLink doesn't necessarily return an absolute path and may return something that's a symlink (ie not recursive)

[dlangBugzillaToGithub]

doob (@jacob-carlborg) commented on 2016-12-17T13:01:41Z

I think we're misunderstanding each other. A potential thisExePathUnresolved function, you obliviously don't that to resolve symbolic links, correct? Do you want that to return the absolute path? I.e. remove any extra "/", "." or "..".

I think that Phobos, as a standard library, should provide a cross-platform consistent behavior for the most common use cases. In my opinion thisExePath is a niche function to begin with, that is most likely not used very often. In general it also more likely that one would _not_ have a symbolic link.

I think with all these cases combined, if that does not fit your use case I think you would have to implement that functionality yourself and not it should not be added to Phobos. The implementation is also very small and already available, you don't need to figure out how to do it on all platforms.

Andrei, what do you think?