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

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@erdani.com
           Assignee|nobody@puremagic.com        |edi33416@gmail.com

--

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

Jacob Carlborg <doob@me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob@me.com

--- Comment #1 from Jacob Carlborg <doob@me.com> ---
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 ".."

--

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

Timothee Cour <timothee.cour2@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timothee.cour2@gmail.com

--- Comment #2 from Timothee Cour <timothee.cour2@gmail.com> ---
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.

--

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

--- Comment #3 from Jacob Carlborg <doob@me.com> ---
(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?

--

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

--- Comment #4 from Timothee Cour <timothee.cour2@gmail.com> ---
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)

--

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

--- Comment #5 from Jacob Carlborg <doob@me.com> ---
(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

--

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

--- Comment #6 from Timothee Cour <timothee.cour2@gmail.com> ---
no, as doc says, asNormalizedPath "Does not resolve symbolic links." realPath would resolve them recursively (just like python realpath)

--

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

--- Comment #7 from Jacob Carlborg <doob@me.com> ---
(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

--

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

--- Comment #8 from Timothee Cour <timothee.cour2@gmail.com> ---
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)

--

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

--- Comment #9 from Jacob Carlborg <doob@me.com> ---
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?

--