Its a very simple problem. When i do `go run...`, i cant use os.Args[0] to find the path of executable, because it will return the path of the build result existing in /tmp.
Which turns to be a problem if i want to path reference relative resources. Being able to discover correctly the path of main, i can start to safely rely on a construction of absolute and relative paths to reference resources available on the FS. Real example, given a repo tree like this, . ├── components │ ├── ... ├── demo │ ├── main.go │ └── static ├── glide.lock ├── mdl │ └── templates ├── view-component.go └── view-component_test.go main is within `demo/`, so if i want to reference `mdl/templates`, a quick though tells that i got to do `..`. Which reveals to be wrong when you go run. It is also wrong if do `go run demo/main.go`, from the top of the repo, because path will be resolved in relative to my cwd. It work only if you cd demo then go run from there. So finding main.go path, within the demo folder, and use it as an anchor to build the path solves both those cases. Also, when it come to deployment, in the idea that those templates are not built into the executable, and that the deployment layout is similar to the development environment, the path resolution will be identical if we assume that the resulting executable takes place of the main.go file. Which is likely to be the case in many situations, yet not all of them, I'm thinking here about an official linux deployment layout which would require to use ldflags or some techniques i m not aware of to redefine the resources location. btw, i took some code from errors pkg, especially the stacktrace producer, thanks for it !! btw², i have another question, to determine if the running executable is produced by go run, or already built, i rely on a detection of os.Args[0] I noticed the path of an executable produced by `go run` would be something like /tmp/gobuildXXXXX/somestuff/src/_ob/main Abstracting the differences from various os (window/ linux), does every GOOS environment follows the same pattern when go run executes ? I ask this because of those environments I don't have obvious idea about how to execute test on like plan9, arm. Its also a topic i wanted to ask about, if anyone knew how to test a go program with automation beyond the obvious windows/linux. On Tuesday, November 15, 2016 at 9:56:05 PM UTC+1, Dave Cheney wrote: > > This smells like the XY problem. What is the problem you are trying to > solve? Or to put it another way, if you could discover the value of GOROOT > associated with a stack trace from a go program, what would you do next? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
