Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

os: provide full path to current executable #4057

Closed
gopherbot opened this issue Sep 10, 2012 · 9 comments
Closed

os: provide full path to current executable #4057

gopherbot opened this issue Sep 10, 2012 · 9 comments

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 10, 2012

by lost.goblin:

It would be very useful to have a way to find the full path to the current executable.

Not sure if this functionality should go in the os or runtime packages, and what would
be a good name. os.Getpath() or os.Getexecpath() perhaps?

For implementation details for most common platforms here is a good reference:
http://stackoverflow.com/a/1024937/192583
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Sep 10, 2012

Comment 1:

Labels changed: added priority-later, packagechange, removed priority-triage.

@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Sep 12, 2012

Comment 2:

This is not possible in general.
I looked at the stack overflow link. Yuck.

Status changed to LongTerm.

@gopherbot

This comment has been minimized.

Copy link
Author

@gopherbot gopherbot commented Sep 19, 2012

Comment 3 by uriel@berlinblue.org:

By "in general" you mean "in a portable way"? Doesn't seem much less portable than
things like os/inotify, and seems to be supported in most platform relatively easily
(just reading a symlink in /proc/ or the like), OS X seems like might be the trickiest.
@minux

This comment has been minimized.

Copy link
Member

@minux minux commented Oct 23, 2012

Comment 4:

I've solved the problem on Darwin (without using cgo, of course), a preview CL is at
https://golang.org/cl/6736069/.
before continue, i'd like to solicit opinions about the new API.
package os
func ExecPath() (string, error)
    ExecPath returns the absolute pathname of the current executing file; if
    error occurs, it will return whatever it current gets and the error.
should it be named GetExecPath()? or some other name?
i think implementing it for rest of supported OSes (except Plan 9) is easy.

Owner changed to @minux.

@minux

This comment has been minimized.

Copy link
Member

@minux minux commented Oct 23, 2012

Comment 5:

https://golang.org/cl/6736069/

Status changed to Started.

@minux

This comment has been minimized.

Copy link
Member

@minux minux commented Nov 6, 2012

Comment 6:

CL 6736069 is rejected mainly because the API whose behavior we can precisely
define (finding the path to re-invoke the current executable) is not what people'd
expect (finding asset files accompanying the executable).
I will extract code from that CL into a separate go-gettable package.

Labels changed: added priority-someday, removed priority-later.

Owner changed to ---.

Status changed to Accepted.

@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 7:

Labels changed: added repo-main.

@matrixik

This comment has been minimized.

Copy link

@matrixik matrixik commented Feb 5, 2014

Comment 8:

You could check `osext` package, it's cross platform:
http://godoc.org/bitbucket.org/kardianos/osext
    func Executable() (string, error)
Executable returns an absolute path that can be used to re-invoke the current program.
It may not be valid after the current program exits.
    func ExecutableFolder() (string, error)
Returns same path as Executable, returns just the folder path. Excludes the executable
name.
@minux

This comment has been minimized.

Copy link
Member

@minux minux commented Feb 6, 2014

Comment 9:

It seems the consensus is that it's not easy to define the semantics of such
an API without referring to the implementation on each platform.

Status changed to Unfortunate.

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.