code review 6736069: runtime, syscall, os: add os.ExecPath() (string, error)

runtime, syscall, os: add os.Executable() (string, error) which returns the path of the current executable. Fixes issue 4057.

[minux1, 2012-10-23 19:04:12]

Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com), I'd like you to review this change to https://code.google.com/p/go/

[minux1, 2012-10-23 19:05:44]

I'd like to solicit opinion about the name and signature of the new func. package os import "os" FUNCTIONS 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.

[bradfitz, 2012-10-23 19:27:40]

https://codereview.appspot.com/6736069/diff/8005/src/pkg/os/execpath_windows.go File src/pkg/os/execpath_windows.go (right): https://codereview.appspot.com/6736069/diff/8005/src/pkg/os/execpath_windows.... src/pkg/os/execpath_windows.go:11: // ExecPath returns the absolute pathname of the current I would only document this once, in a common file, like: // ExecPath returns ... func ExecPath() (string, error) { return execPath() } And then implement the lowercase OS-specific execPath in +build-restricted files.

[bradfitz, 2012-10-23 19:27:57]

I like the API addition, but the name sounds too imperative to me (like it's going to try go "exec" the provided path). It doesn't sound like a getter. On Tue, Oct 23, 2012 at 12:05 PM, <minux.ma@gmail.com> wrote: > I'd like to solicit opinion about the name and signature of the new > func. > > package os > import "os" > > FUNCTIONS > 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. > > https://codereview.appspot.**com/6736069/<https://codereview.appspot.com/6736... > 

[minux1, 2012-10-23 19:37:48]

On Wed, Oct 24, 2012 at 3:27 AM, Brad Fitzpatrick <bradfitz@golang.org>wrote: > I like the API addition, but the name sounds too imperative to me (like > it's going to try go "exec" the provided path). It doesn't sound like a > getter. How about GetExecPath() or GetProcPath() ? 

[bradfitz, 2012-10-23 19:48:54]

On Tue, Oct 23, 2012 at 12:37 PM, minux <minux.ma@gmail.com> wrote: > > On Wed, Oct 24, 2012 at 3:27 AM, Brad Fitzpatrick <bradfitz@golang.org>wrote: > >> I like the API addition, but the name sounds too imperative to me (like >> it's going to try go "exec" the provided path). It doesn't sound like a >> getter. > > How about GetExecPath() or GetProcPath() ? > Go generally avoids the prefix "Get". The existing functions named "Get" in the os package are named after common libc/syscall functions. 

[minux1, 2012-10-23 19:56:15]

On Wed, Oct 24, 2012 at 3:48 AM, Brad Fitzpatrick <bradfitz@golang.org>wrote: > > On Tue, Oct 23, 2012 at 12:37 PM, minux <minux.ma@gmail.com> wrote: > >> >> On Wed, Oct 24, 2012 at 3:27 AM, Brad Fitzpatrick <bradfitz@golang.org>wrote: >> >>> I like the API addition, but the name sounds too imperative to me (like >>> it's going to try go "exec" the provided path). It doesn't sound like a >>> getter. >> >> How about GetExecPath() or GetProcPath() ? >> > > Go generally avoids the prefix "Get". The existing functions named "Get" > in the os package are named after common libc/syscall functions. > how about os.CurrentExecutablePath() ? this function won't be frequently used, so a slightly longer name is acceptable imo. 

[bradfitz, 2012-10-23 21:33:26]

On Tue, Oct 23, 2012 at 12:55 PM, minux <minux.ma@gmail.com> wrote: > > On Wed, Oct 24, 2012 at 3:48 AM, Brad Fitzpatrick <bradfitz@golang.org>wrote: >> >> On Tue, Oct 23, 2012 at 12:37 PM, minux <minux.ma@gmail.com> wrote: >> >>> >>> On Wed, Oct 24, 2012 at 3:27 AM, Brad Fitzpatrick <bradfitz@golang.org>wrote: >>> >>>> I like the API addition, but the name sounds too imperative to me (like >>>> it's going to try go "exec" the provided path). It doesn't sound like a >>>> getter. >>> >>> How about GetExecPath() or GetProcPath() ? >>> >> >> Go generally avoids the prefix "Get". The existing functions named "Get" >> in the os package are named after common libc/syscall functions. >> > how about os.CurrentExecutablePath() ? > > this function won't be frequently used, so a slightly longer name is > acceptable imo. > "Current" implies that it can change over time. Which I guess is true, if chroot is called? CurrentExecutablePath seems okay to me, if a little long, but I defer to others. 

[remyoudompheng, 2012-10-23 21:35:17]

What about "ProgramPath"? unless program is ambiguous and could refer to source code?

[minux1, 2012-10-24 04:15:53]

On Oct 24, 2012 5:33 AM, "Brad Fitzpatrick" <bradfitz@golang.org> wrote: > "Current" implies that it can change over time. Which I guess is true, if chroot is called? unfortunately, at least on some systems the value won't change over time. > CurrentExecutablePath seems okay to me, if a little long, but I defer to others. how about StartupExecutablePath() then? it emphasizes that the returned value is corresponding to the moment the program starts, which is correct meaning. oh, it seems we must store cwd at program start to give accurate path (some machenisms can return relative paths). 

[minux1, 2012-10-24 04:18:06]

On Oct 24, 2012 5:35 AM, <remyoudompheng@gmail.com> wrote: > What about "ProgramPath"? unless program is ambiguous and could refer to > source code? i think it's ok. but i'd prefer StartupProgramPath now. 

[brainman, 2012-10-24 04:19:15]

LGTM, but wait for others. Alex http://codereview.appspot.com/6736069/diff/16026/src/pkg/os/execpath_test.go File src/pkg/os/execpath_test.go (right): http://codereview.appspot.com/6736069/diff/16026/src/pkg/os/execpath_test.go#... src/pkg/os/execpath_test.go:12: oexec "os/exec" why rename? http://codereview.appspot.com/6736069/diff/16026/src/pkg/os/execpath_test.go#... src/pkg/os/execpath_test.go:21: t.Errorf("ExecPath failed: %v", err) s/Errorf/Fatalf/ then you will not need the following "return". Same everywhere else. http://codereview.appspot.com/6736069/diff/16026/src/pkg/syscall/syscall_wind... File src/pkg/syscall/syscall_windows.go (right): http://codereview.appspot.com/6736069/diff/16026/src/pkg/syscall/syscall_wind... src/pkg/syscall/syscall_windows.go:774: func GetModuleFileName(handle Handle) (string, error) { Please, move this to os. Provide GetModuleFileName, as it is published in windows api, instead. http://codereview.appspot.com/6736069/diff/16026/src/pkg/syscall/syscall_wind... src/pkg/syscall/syscall_windows.go:783: if r == n { I would revert the condition and break first. Then you will not need continue.

[minux1, 2012-10-24 04:31:11]

thank you. On Oct 24, 2012 12:19 PM, <alex.brainman@gmail.com> wrote: > http://codereview.appspot.com/6736069/diff/16026/src/pkg/os/execpath_test.go#... > src/pkg/os/execpath_test.go:12: oexec "os/exec" > why rename? because the os package has a function named exec. > http://codereview.appspot.com/6736069/diff/16026/src/pkg/syscall/syscall_wind... > src/pkg/syscall/syscall_windows.go:774: func GetModuleFileName(handle > Handle) (string, error) { > Please, move this to os. Provide GetModuleFileName, as it is published > in windows api, instead. i think os is just for portable functions. doesn't this function belong to pkg syscall? i can export the original verion of the api in syscall, but the user still needs to write some code to use it in Go properly. btw, what's your opinion about the new api? do you have suggestions about its name? 

[brainman, 2012-10-24 05:47:25]

On 2012/10/24 04:31:11, minux wrote: > > ... > > Please, move this to os. Provide GetModuleFileName, as it is published > > in windows api, instead. > i think os is just for portable functions. > doesn't this function belong to pkg syscall? Do not export os.GetModuleFileName. You already have *_windows.go file - put all your code in there. And do not export it from os. > > i can export the original verion of the api in > syscall, ... Yes, please leave api as per Microsoft documentation (just leave //sys line). If someone decides to use it in some particular way, it is as documented. > ... but the user still needs to write some > code to use it in Go properly. Sure. This is syscall package - no batteries included. :-) > ... > do you have suggestions about its name? Getppath. Just joking. I do not have good suggestions. Alex

[taruti, 2012-10-24 07:30:00]

We frequently run go things inside chroots without /proc - please don't make this impossible. Just having this API does not break things, but any code in the stdlib depending on this working would be nasty.

[minux1, 2012-10-24 08:12:42]

On 2012/10/24 07:30:00, taruti wrote: > We frequently run go things inside chroots without /proc - please don't make > this impossible. Just having this API does not break things, but any code in the the fact that this API depends on procfs doesn't mean you cannot run Go programs without procfs, you just cannot use the new API. > stdlib depending on this working would be nasty. Why? procfs is standard part of Linux, and lots of things will break if it's missing. I think you must understand this implication when you chroot to a directory without procfs. for instance, the os package is already using /proc/sys/kernel/hostname to get the hostname. Because procfs is a integrated part of linux, there are problems that are not solvable without it (for example, ps(1)), AFAIK. However, if you could provide a portable way to implement this API on Linux without resorting to procfs, i'd like to adapt it. (by portable, I mean it needs to support Linux 2.6.23+)

[kardia, 2012-10-24 16:23:37]

I'd personally like this to go it. If there is a dependency on /proc on linux, then we can document that as a BUG for now(?). I've already coded similar code for linux,windows, and osx (using cgo), so I personally require and use the functionality this provides on multiple platforms. I think this would also be fine for a go get package, but osx requires runtime changes for this to work without cgo. name suggestion? ProcessFilePath(), ProcessPath() Use cases for this call: * Get a path to the exec when creating a "service" on windows, upstart, launchd. * I often bundle resources next to the exec for easy deployment. Without this I have to watch my working directory when I call it. Not horrible, but much easier just to get the path the OS already knows, no guesswork required, same deployment on all systems. .. I understand these use cases are not relevant for many projects for many people, but they are useful to me, especially when I have a number of smaller one off projects on different platforms, it greatly simplifies my code and deployment to use this functionality... On Wednesday, October 24, 2012 1:12:43 AM UTC-7, minux wrote: > > On 2012/10/24 07:30:00, taruti wrote: > > We frequently run go things inside chroots without /proc - please > don't make > > this impossible. Just having this API does not break things, but any > code in the > the fact that this API depends on procfs doesn't mean you cannot run Go > programs > without procfs, you just cannot use the new API. > > stdlib depending on this working would be nasty. > Why? procfs is standard part of Linux, and lots of things will break if > it's missing. > I think you must understand this implication when you chroot to a > directory > without procfs. > > for instance, the os package is already using /proc/sys/kernel/hostname > to > get the hostname. Because procfs is a integrated part of linux, there > are problems > that are not solvable without it (for example, ps(1)), AFAIK. > > However, if you could provide a portable way to implement this API on > Linux > without resorting to procfs, i'd like to adapt it. > (by portable, I mean it needs to support Linux 2.6.23+) > > https://codereview.appspot.com/6736069/ > 

[bradfitz, 2012-10-24 20:08:05]

ProcessPath is the best name I've heard. On Wed, Oct 24, 2012 at 9:23 AM, Daniel Theophanes <kardianos@gmail.com>wrote: > I'd personally like this to go it. If there is a dependency on /proc on > linux, then we can document that as a BUG for now(?). I've already coded > similar code for linux,windows, and osx (using cgo), so I personally > require and use the functionality this provides on multiple platforms. I > think this would also be fine for a go get package, but osx requires > runtime changes for this to work without cgo. > > name suggestion? ProcessFilePath(), ProcessPath() > > Use cases for this call: > * Get a path to the exec when creating a "service" on windows, upstart, > launchd. > * I often bundle resources next to the exec for easy deployment. > Without this I have to watch my working directory when I call it. Not > horrible, > but much easier just to get the path the OS already knows, no guesswork > required, > same deployment on all systems. > > .. I understand these use cases are not relevant for many projects for > many people, but they > are useful to me, especially when I have a number of smaller one off > projects on different platforms, > it greatly simplifies my code and deployment to use this functionality... > > > On Wednesday, October 24, 2012 1:12:43 AM UTC-7, minux wrote: >> >> On 2012/10/24 07:30:00, taruti wrote: >> > We frequently run go things inside chroots without /proc - please >> don't make >> > this impossible. Just having this API does not break things, but any >> code in the >> the fact that this API depends on procfs doesn't mean you cannot run Go >> programs >> without procfs, you just cannot use the new API. >> > stdlib depending on this working would be nasty. >> Why? procfs is standard part of Linux, and lots of things will break if >> it's missing. >> I think you must understand this implication when you chroot to a >> directory >> without procfs. >> >> for instance, the os package is already using /proc/sys/kernel/hostname >> to >> get the hostname. Because procfs is a integrated part of linux, there >> are problems >> that are not solvable without it (for example, ps(1)), AFAIK. >> >> However, if you could provide a portable way to implement this API on >> Linux >> without resorting to procfs, i'd like to adapt it. >> (by portable, I mean it needs to support Linux 2.6.23+) >> >> https://codereview.appspot.**com/6736069/<https://codereview.appspot.com/6736... >> > 

[minux1, 2012-10-25 05:38:17]

PTAL. Patch Set 22 is using the name ProgramPath. I've tested on Mac OS X 10.6/amd64, Linux/amd64, FreeBSD 9/amd64, NetBSD 6/amd64, Windows/386. (OpenBSD is known to fail, because it doesn't provide procfs by default, and I couldn't find an alternative way)

[brainman, 2012-10-25 06:25:09]

https://codereview.appspot.com/6736069/diff/32004/src/pkg/os/progpath_test.go File src/pkg/os/progpath_test.go (right): https://codereview.appspot.com/6736069/diff/32004/src/pkg/os/progpath_test.go... src/pkg/os/progpath_test.go:12: oexec "os/exec" You didn't tell me why you are renaming "os/exec" to oexec.

[minux1, 2012-10-25 06:29:50]

On Thu, Oct 25, 2012 at 2:25 PM, <alex.brainman@gmail.com> wrote: > https://codereview.appspot.**com/6736069/diff/32004/src/** > pkg/os/progpath_test.go#**newcode12<https://codereview.appspot.com/6736069/diff/32004/src/pkg/os/progpath_test.go#newcode12> > src/pkg/os/progpath_test.go:**12: oexec "os/exec" > You didn't tell me why you are renaming "os/exec" to oexec. > https://codereview.appspot.com/6736069/#msg13 there is a function named exec in pkg os_test (file os_test.go). 

[brainman, 2012-10-25 06:32:08]

On 2012/10/25 06:29:50, minux wrote: > ... > there is a function named exec in pkg os_test (file os_test.go). Ah, yes. Thank you. :-) Alex

[rsc, 2012-10-25 21:16:49]

Sorry, but ProcessPath sounds like you are processing a path. Let's wait on this until Rob's back (next week). 

[r, 2012-10-26 16:26:49]

how about "Executable"? 

[minux1, 2012-10-26 16:31:18]

On Saturday, October 27, 2012, Rob Pike wrote: > how about "Executable"? > without mentioning path? 

[r, 2012-10-26 16:36:37]

On Fri, Oct 26, 2012 at 9:31 AM, minux <minux.ma@gmail.com> wrote: > > On Saturday, October 27, 2012, Rob Pike wrote: >> >> how about "Executable"? > > without mentioning path? is your name minuxName? -rob 

[minux1, 2012-10-28 15:43:54]

On 2012/10/26 16:36:37, r wrote: > is your name minuxName? good point. PTAL. btw, how to implement this on Plan 9?

[r, 2012-10-28 15:48:45]

The file names are inappropriate now. For Plan 9, it depends what you want this for. /proc/PID/text is always a working name for the executable. Otherwise I don't know if it's possible. -rob 

[minux1, 2012-10-28 15:57:44]

On 2012/10/28 15:48:45, r wrote: > The file names are inappropriate now. do you have suggestions for the filenames? i think executable is a bit too long, and exec might confuse with the exec syscall. how about the original execpath? > For Plan 9, it depends what you want this for. /proc/PID/text is > always a working name for the executable. Otherwise I don't know if > it's possible. I've thought about /proc/PID/text, in fact it can pass the test, but i think the main use of this to determine the original binary's path so that the binary can access its bundled asset files, for example. i'd also like to test we can indeed find the other files around the binary, but given the current go test's behavior, this is difficult to test.

[minux1, 2012-10-28 17:35:09]

PTAL. Patch Set 24 is the same as Patch Set 23 except s/progpath/executable/ in filenames.

[r, 2012-10-28 17:47:49]

i'm still not convinced by the idea behind this. the idea seems intrinsically too unportable to be elevated to the standard library. i expect to be outvoted. https://codereview.appspot.com/6736069/diff/43014/src/pkg/os/executable.go File src/pkg/os/executable.go (right): https://codereview.appspot.com/6736069/diff/43014/src/pkg/os/executable.go#ne... src/pkg/os/executable.go:7: // Executable returns the absolute pathname of the current "the absolute pathname" sounds definitive but is actually not well-defined. https://codereview.appspot.com/6736069/diff/43014/src/pkg/os/executable_darwi... File src/pkg/os/executable_darwin.go (right): https://codereview.appspot.com/6736069/diff/43014/src/pkg/os/executable_darwi... src/pkg/os/executable_darwin.go:7: var progPath string // set by ../runtime/progpath_darwin.c you've still got some progpaths around, in different casings.

[minux1, 2012-10-28 18:18:41]

On 2012/10/28 17:47:49, r wrote: https://codereview.appspot.com/6736069/diff/43014/src/pkg/os/executable.go#ne... > src/pkg/os/executable.go:7: // Executable returns the absolute pathname of the > current > "the absolute pathname" sounds definitive but is actually not well-defined. i agree it is difficult to define its precise behavior. however, i think the following description is reasonable: the return value of Executable is an absolute path that matches the path used to launch the executable (assuming no one is modifying the intermediate paths). https://codereview.appspot.com/6736069/diff/43014/src/pkg/os/executable_darwi... > src/pkg/os/executable_darwin.go:7: var progPath string // set by > ../runtime/progpath_darwin.c > you've still got some progpaths around, in different casings. All fixed.

[ality, 2012-10-29 01:06:08]

minux.ma@gmail.com once said: > On 2012/10/26 16:36:37, r wrote: > >is your name minuxName? > good point. PTAL. > > btw, how to implement this on Plan 9? func executable() (string, error) {	f, err := Open("/proc/" + itoa(Getpid()) + "/text")	if err != nil {	return "", err	}	defer f.Close()	return syscall.Fd2path(int(f.Fd())) } 

[minux1, 2012-10-30 15:50:03]

PTAL. All supported OSes have working implementations now. Except perhaps OpenBSD, where procfs is not mounted by default, but I don't know any alternatives. +jsing. On 2012/10/29 01:06:08, ality wrote: > > btw, how to implement this on Plan 9? > func executable() (string, error) { >	f, err := Open("/proc/" + itoa(Getpid()) + "/text") >	if err != nil { >	return "", err >	} >	defer f.Close() >	return syscall.Fd2path(int(f.Fd())) > } Thank you. I originally assumed fd2path on /proc/PID/text would return "/proc/PID/text".

[ality, 2012-10-30 21:13:50]

minux.ma@gmail.com once said: > On 2012/10/29 01:06:08, ality wrote: > >> btw, how to implement this on Plan 9? > >func executable() (string, error) { > >	f, err := Open("/proc/" + itoa(Getpid()) + "/text") > >	if err != nil { > >	return "", err > >	} > >	defer f.Close() > >	return syscall.Fd2path(int(f.Fd())) > >} > Thank you. I originally assumed fd2path on /proc/PID/text would > return "/proc/PID/text". Yeah, that's a reasonable assumption but the man page for fd2path(2) is careful with its words. There are only a few places in the kernel where this distinction is made. The prime example is the dup(3) device: when you open either of the fd files, a reference to the underlying channel is returned. It's similar for /proc/$pid/text. When you call exec(2) on an executable file, the kernel opens the file internally and saves a reference to the corresponding channel (along with some other state) into something called the "image cache". Then, when you open /proc/$pid/text, the original channel is retrieved from the cache and returned. 

[rsc, 2012-10-30 21:29:45]

https://codereview.appspot.com/6736069/diff/37032/src/pkg/os/executable.go File src/pkg/os/executable.go (right): https://codereview.appspot.com/6736069/diff/37032/src/pkg/os/executable.go#ne... src/pkg/os/executable.go:7: // Executable returns the absolute pathname of the current In general this is impossible, of course, so it would be nice to be more specific about what the return value is good for. For example, if we wrote: // Executable returns a path that can be used to reinvoke the current program. // It may not be valid after the current program exits. then on Linux you could just return "/proc/PID/exe" and on Plan 9 "/proc/PID/text". On the other hand, if there are subtler reasons for wanting this information, like trying to find associated files, then we'd need to be more clear that those are not acceptable answers. Personally, I don't believe we should try to support that use case, so my inclination would be to use just the description above and not do any kind of readlink or fd2path or anything like that.

[minux1, 2012-10-30 21:44:20]

On Wed, Oct 31, 2012 at 5:29 AM, <rsc@golang.org> wrote: > src/pkg/os/executable.go:7: // Executable returns the absolute pathname > of the current > In general this is impossible, of course, so it would be nice to be more > specific about what the return value is good for. > Why impossible in general? Assumes nothing changes the environment (that is, nothing renames files, deletes files, etc.), this CL implemented the behavior on all supported OSes. 

[r, 2012-10-30 21:46:03]

Names are not unique, well-defined, or stable. It's the kind of thing that usually works but won't always, and the failures will be subtle. Code that depends on this interface will be buggy and maybe insecure. -rob 

[kardia, 2012-10-31 03:42:01]

As an observation, what you have mentioned is true, but is true for any path related api, such as os,Getwd(), or even os.Open. You don't actually know for sure that is correct until tested. And granted, some situations the path is more unstable then others. As an observer, I continue to not see the argument against it, though I understand it may not be useful to you. But this being my last comment here, should this not go in, I'll move what I can (most everything except darwin) into a third party package (if that's alright with minux to use his code for some of the platforms I don't have). -Daniel On Oct 30, 2012 2:46 PM, "Rob Pike" <r@golang.org> wrote: > > Names are not unique, well-defined, or stable. It's the kind of thing > that usually works but won't always, and the failures will be subtle. > Code that depends on this interface will be buggy and maybe insecure. > > -rob 

[r, 2012-10-31 03:46:35]

No one has answered Russ's question (and mine). What is this _for_? -rob 

[kardia, 2012-10-31 03:52:43]

This is what I currently use this call for on Windows, Linux, and darwin right now: * Get a path to the exec when creating a "service" on windows, upstart, launchd. * I often bundle resources next to the exec for easy deployment. Without this I have to watch my working directory when I call it. Not horrible, but much easier just to get the path the OS already knows, no guesswork required, same deployment on all systems. Prior to this * On Linux I had to be sure to set the WD before starting (with nohup). * Couldn't get related files without this on Windows at all when running as a windows service. Does this answer your question? Thanks, -Daniel On Tuesday, October 30, 2012 8:46:40 PM UTC-7, Rob Pike wrote: > > No one has answered Russ's question (and mine). What is this _for_? > > -rob > 

[rsc, 2012-11-01 16:46:51]

Using "Executable" to find related files bothers me quite a bit. I think Go doesn't have a good story for finding associated files, but if we want to address that I think we should do it head on instead of slipping it into a mostly unrelated function. If this were just for re-running the current executable I wouldn't mind. But it sounds like that's not why people want it. So my inclination is to leave it out for now. 

[minux1, 2012-11-01 16:55:44]

On Fri, Nov 2, 2012 at 12:46 AM, Russ Cox <rsc@golang.org> wrote: > Using "Executable" to find related files bothers me quite a bit. I > think Go doesn't have a good story for finding associated files, but > if we want to address that I think we should do it head on instead of > slipping it into a mostly unrelated function. > > If this were just for re-running the current executable I wouldn't > mind. But it sounds like that's not why people want it. So my > inclination is to leave it out for now. > OK, fair enough. I think we can do this. stop saying that the return path can be used to find related files (it just happen to be able to do this on major platforms, just readlink the returned path), and just address the re-running the current executable problem. I will remove all Readlink calls, and instead just return something like /proc/self/exe (I will keep the Plan 9 code, because the solution is not apparent). what do you think? 

[rsc, 2012-11-01 17:23:10]

If we limit Executable to that smaller scope it sounds like no one wants it anymore. So I would be inclined to leave it out. Russ 

[minux1, 2012-11-01 17:26:46]

On Fri, Nov 2, 2012 at 1:23 AM, Russ Cox <rsc@golang.org> wrote: > If we limit Executable to that smaller scope it sounds like no one > wants it anymore. So I would be inclined to leave it out. > Darwin, FreeBSD, Windows and Plan 9 all have non-trivial implementation for os.Executable (e.g. don't return a constant string) 

[rsc, 2012-11-01 17:30:33]

The complexity of the implementation needs to be paid for by general utility. I haven't heard anyone claiming they need or would use this function (except to find associated files, which I don't want to support this way). Russ 

[bradfitz, 2012-11-01 17:35:57]

I would use this in things like gorunas, launching child processes of myself, since we don't have fork. In tests I always just use os.Args(0) which isn't guaranteed to be portable or even work always on Linux. On Nov 1, 2012 6:30 PM, "Russ Cox" <rsc@golang.org> wrote: > The complexity of the implementation needs to be paid for by general > utility. I haven't heard anyone claiming they need or would use this > function (except to find associated files, which I don't want to > support this way). > > Russ > 

[rsc, 2012-11-01 17:49:57]

If you change the doc comment to // Executable returns a path that can be used to reinvoke the current program. // It may not be valid after the current program exits. and simplify the Plan 9 and Linux implementations, then I'll go along with this. (On Plan 9 use /proc/+itoa(pid)+/text.) On Thu, Nov 1, 2012 at 1:35 PM, Brad Fitzpatrick <bradfitz@golang.org> wrote: > I would use this in things like gorunas, launching child processes of > myself, since we don't have fork. > > In tests I always just use os.Args(0) which isn't guaranteed to be portable > or even work always on Linux. > > On Nov 1, 2012 6:30 PM, "Russ Cox" <rsc@golang.org> wrote: >> >> The complexity of the implementation needs to be paid for by general >> utility. I haven't heard anyone claiming they need or would use this >> function (except to find associated files, which I don't want to >> support this way). >> >> Russ 

[r, 2012-11-01 19:20:40]

I'd still prefer to leave it out, for the reasons rsc said. I still believe it's a weak solution to a poorly-defined problem that's not the one most people actually want solved. and once it goes in we can't take it out or change its semantics to be something genuinely useful. That's not a veto, just a statement of preference. One use case does not a must-last-forever feature make. -rob 

[minux1, 2012-11-01 20:00:53]

PTAL. On 2012/11/01 17:49:57, rsc wrote: > If you change the doc comment to > // Executable returns a path that can be used to reinvoke the current > program. > // It may not be valid after the current program exits. > > and simplify the Plan 9 and Linux implementations, then I'll go along with > this. > (On Plan 9 use /proc/+itoa(pid)+/text.) Done. On 2012/11/01 19:20:40, r wrote: > I'd still prefer to leave it out, for the reasons rsc said. I still > believe it's a weak solution to a poorly-defined problem that's not now the problem is well defined: return a absolute path to re-invoke the same program. > the one most people actually want solved. and once it goes in we can't > take it out or change its semantics to be something genuinely useful. On Unix systems, you simply readlink the returned string, and you will get what you want. we just don't make that guarantee.

[taruti, 2012-11-01 22:14:01]

Why not simply have a (using os/exec): func SelfCommand(arg ...string) (*exec.Cmd, error) If the idea is to have re-execute the current command. Would be much cleaner and allow for potentially better implementations.

[aram, 2012-11-02 09:59:53]

A very big -1 on this change. The original problem was "how to find assets bundled with binaries", a potentially valid concern, but when we found we can't solve that problem with the input we had, we decided to search for a new problem that fit the already implemented solution, "how to return a absolute path to re-invoke the same program", a problem no one asked. The semantics are different on each operating system, and on Plan 9 they don't make sense at all. -- Aram 

[minux1, 2012-11-02 12:07:30]

On Fri, Nov 2, 2012 at 5:59 PM, Aram Hăvărneanu <aram@mgk.ro> wrote: > A very big -1 on this change. The original problem was "how to find > assets bundled with binaries", a potentially valid concern, but when > we found we can't solve that problem with the input we had, we decided > to search for a new problem that fit the already implemented solution, > "how to return a absolute path to re-invoke the same program", a > problem no one asked. > As I've explained, my original patch set does implement the required behavior on all supported OSes. The problem is how to write correct document for it (e.g. how to precisely define the behavior). > > The semantics are different on each operating system, and on Plan 9 > they don't make sense at all. > Why they don't make sense on Plan 9? To obtain proper asset filepath, you can do this to path obtained from Executable: On Unix, just readlink the returned path. On Plan 9, you need to open that file, and fd2path. On Windows, you don't need to do anything. 

[rsc, 2012-11-02 20:20:33]

There is enough disagreement about this that I would like to leave it for a 3rd-party package to implement, at least for now. I don't want to add an API that we'll be stuck with and regret. Thanks. Russ 

[kardia, 2012-11-02 20:23:38]

Would it be possible to get in a CL just for darwin, and only have the call in syscall? On Fri, Nov 2, 2012 at 1:20 PM, Russ Cox <rsc@golang.org> wrote: > There is enough disagreement about this that I would like to leave it > for a 3rd-party package to implement, at least for now. I don't want > to add an API that we'll be stuck with and regret. > > Thanks. > Russ > 

[minux1, 2012-11-03 06:15:11]

On Sat, Nov 3, 2012 at 4:20 AM, Russ Cox <rsc@golang.org> wrote: > There is enough disagreement about this that I would like to leave it > for a 3rd-party package to implement, at least for now. I don't want > to add an API that we'll be stuck with and regret. > It's fine for me to move this into a go-gettable package. I've found ways to implement the required functionality on Darwin without runtime changes. What about issue 4057? Should I close it with status unfortunate? 

[rsc, 2012-11-06 19:35:30]

Let's leave 4057 as priority-someday. Thanks. 

[ality, 2013-07-20 06:50:57]

Removing myself from reviewers.

[rsc, 2013-12-18 04:11:02]

R=close