Bug 16595 – thisExePath resolves symlinks but this isn't mentioned in docs

``` 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?

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 ".."

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.

(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?

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)

(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

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

(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

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)

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?

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/phobos/issues/9694 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB