kardianos / osext Goto Github PK

Hello,

I'm using a Go app that uses osext on Android (with Termux) and I get this error:

panic: ExecPath not implemented for android

It seems runtime.GOOS == "android" on Android but /proc/self/exe works just like on Linux.
So doing this is enough to make it work for me:

diff --git a/vendor/github.com/kardianos/osext/osext_procfs.go b/vendor/github.com/kardianos/osext/osext_procfs.go
index d59847e..1318041 100644
--- a/vendor/github.com/kardianos/osext/osext_procfs.go
+++ b/vendor/github.com/kardianos/osext/osext_procfs.go
@@ -16,7 +16,7 @@ import (
 
 func executable() (string, error) {
        switch runtime.GOOS {
-       case "linux":
+       case "android":
                const deletedTag = " (deleted)"
                execpath, err := os.Readlink("/proc/self/exe")
                if err != nil {

Hi guys,

Since you copied the code from the Go Language project, and give full credit in the headers to them, does the patents provision still hold?
If so, could you please update your project to include the patents file from the Go Language project?

Thanks

The Commit 9b883c5 breaks the fix for OpenBSD in b4814f4 since go still expects procfs on OpenBSD (see: https://github.com/golang/go/blob/master/src/os/executable_procfs.go#L26)

I already opened an Issue (golang/go#19453) but still would suggest to use the osext.Executable for go1.8+ on OpenBSD.

diff --git a/osext_go18.go b/osext_go18.go
index 7065a5f..cb1d168 100644
--- a/osext_go18.go
+++ b/osext_go18.go
@@ -1,3 +1,4 @@
+//+build !openbsd
 //+build go1.8

 package osext
diff --git a/osext_sysctl.go b/osext_sysctl.go
index 579f224..33cee25 100644
--- a/osext_sysctl.go
+++ b/osext_sysctl.go
@@ -2,7 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.

-// +build !go1.8,darwin !go1.8,freebsd !go1.8,openbsd
+// +build !go1.8,darwin !go1.8,freebsd openbsd

 package osext

go test without the fix:

--- FAIL: TestPrintExecutable (0.00s)
        osext_test.go:30: Executable failed: readlink /proc/curproc/file: no such file or directory
--- FAIL: TestPrintExecutableFolder (0.00s)
        osext_test.go:37: ExecutableFolder failed: readlink /proc/curproc/file: no such file or directory
--- FAIL: TestExecutableFolder (0.00s)
        osext_test.go:44: ExecutableFolder failed: readlink /proc/curproc/file: no such file or directory
--- FAIL: TestExecutableMatch (0.00s)
        osext_test.go:53: Executable failed: readlink /proc/curproc/file: no such file or directory
FAIL
exit status 1
FAIL    github.com/kardianos/osext      0.017s

Seems relatively stable, and to more easily work with Go modules, it would be nice if this were just tagged / released as v1.0.0

I'm trying to create a package of this go library for fedora, but the tests fail inconsistently. About 3/12 times the tests fail, and the error looks like a race condition to me (which is supported by the fact that this happens mostly in the slowest build VMs: 2 x aarch64, 1 x ppc64le).

+ go test -compiler gc -ldflags '' github.com/kardianos/osext
--- FAIL: TestExecutableDelete (0.00s)
	osext_test.go:135: Child returned "/tmp/go-build761114003/github.com/kardianos/osext/_test/osext.test (deleted)", not the same file as "/tmp/go-build761114003/github.com/kardianos/osext/_test/osext.test"
FAIL
FAIL	github.com/kardianos/osext	0.007s

Is there anything I can do about that, or is it a bug?

To reproduce:

• build the binary, e.g. "km"
• start a process running "km" with some args
• delete the "km" binary
• re-build the "km" binary
• signal the already-running "km" process to spawn a child "km" process using osext.Executable() to determine the path to the binary
• OBSERVE: Executable() returns "km (deleted)" instead of "km"

$ uname -a
Linux development-3273-e3e 3.16-0.bpo.2-amd64 #1 SMP Debian 3.16.3-2~bpo70+1 (2014-09-21) x86_64 GNU/Linux

I'm on a CentOS Linux release 7.1.1503 (Core) machine and osext.Executable() returns /usr/bin/.myexe.old instead of /usr/bin/myexe after the initial executable gets changed.

I see in osext_procfs.go that (deleted) gets trimmed, but in this case it is not enough.

Do we want to trim . and .old also?

On MacOS when I call osext.Executable() I get exactly what the documentation promises:

Executable returns an absolute path that can be used to re-invoke the current program

On Windows however I only get the name of the executable file (no path).

folderPath, err := osext.ExecutableFolder()
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(folderPath)

Output:
/var/folders/j3/0pdflnzn5zx7scbsr24g0fsr0000gn/T/go-build162307922/command-line-arguments/_obj/exe

or Is there a better way to get a current directory on OSX?

Just saw this sporadic failure: https://travis-ci.org/daaku/rell/builds/57893018

--- FAIL: TestExecutableDelete-2 (0.08s)
    osext_test.go:109: Child returned " (deleted)/tmp/go-build754787391/github.com/daaku/rell/internal/github.com/kardianos/osext/_test/osext.test", want an absolute path
FAIL
FAIL    github.com/daaku/rell/internal/github.com/kardianos/osext   0.116s

Looks like the (deleted) is throwing it off?

My screen shows the information that it is not compatible with windows, correct?

go run server.go

can only fetch the temporary executable

/private/var/folders/g7/psb64vj106321f1k80jj1frc0000gn/T/go-build519666050/command-line-arguments/_obj/exe/serve

Hello. I came across your repository from https://github.com/DannyBen/gondl
which used your bitbucket repo https://bitbucket.org/kardianos/osext
It seems the bitbucket repository is out-of-date.
Perhaps put a note there about this github repo?
Thanks :)

Hi,

I have a question about this package. I see it has a lot of internal code for each platform that performs low level operations to find out the executable name.

Can you please explain in what situations the output of osext.Executable() would differ from doing a much simpler operation to find out the executable path, by accessing os.Args[0]? Why should users use osext.Executable() instead of os.Args[0]? I'd like to understand this better.

Thank you!

Mostly just an annoyance when developing on Mac. Switch doesn't include 'darwin' for the GOOS.

Hello,
I found that osext.ExecutableFolder() returns incorrect path when running "go run" on OSX since Go 1.6:

fork/exec /private/var/folders/d3/vdcdk3yx5f94ddnpbl0wtxyc0000gn/T/go-build785614328/command-line-arguments/_obj/exe/Electron: no such file or directory

• osext works on "go build" as usual.

I'd be glad if you fix this.

In this case:
bin dir or any parent dir of bin dir is a symlink to other dir, readlink returns an incorrect full path for exec. This is not easy to make user understand. And in some cases, the real path of that link may not in $PATH env.

I make a little change in the function executable as following:

--- osext-master/osext_procfs.go        2015-12-22 23:32:29.000000000 +0800
+++ osext/osext_procfs.go       2016-02-04 16:31:20.000000000 +0800
@@ -10,21 +10,23 @@
        "errors"
        "fmt"
        "os"
+       "os/exec"
        "runtime"
        "strings"
+       "path/filepath"
 )

 func executable() (string, error) {
        switch runtime.GOOS {
        case "linux":
-               const deletedTag = " (deleted)"
-               execpath, err := os.Readlink("/proc/self/exe")
-               if err != nil {
-                       return execpath, err
+               if strings.HasPrefix(os.Args[0], "/") {
+                       return os.Args[0], nil
+               } else if strings.Contains(os.Args[0], "/") {
+                       var cwd, _ = os.Getwd()
+                       return filepath.Join(cwd, os.Args[0]), nil
+               } else {
+                       return exec.LookPath(os.Args[0])
                }
-               execpath = strings.TrimSuffix(execpath, deletedTag)
-               execpath = strings.TrimPrefix(execpath, deletedTag)
-               return execpath, nil
        case "netbsd":
                return os.Readlink("/proc/curproc/exe")
        case "dragonfly":

To make code clear to understand, some error processings are ignored in above.

And I dont know what the behavior of bsd or solaris, so I just changed the code of linux. But I think they should be the same.

The return from GetModuleFileName is not a size on all windows versions, its more success of failure indicator.

func getModuleFileName() (string, error) {
    b := make([]uint16, syscall.MAX_PATH)
    r0, _, e1 := getModuleFileNameProc.Call(0, uintptr(unsafe.Pointer(&b[0])), uintptr(uint32(len(b))))
    if r0 == 0 {
        return "", e1
    }

    return syscall.UTF16ToString(b), nil
}

Since I found your staticserv (repository now defunct?) utility quite useful, I created a mirror on GitHub. I since them updated the build environment to use Go modules.

Could you please release a semantically versioned release of osext? Having to require github.com/kardianos/osext v0.0.0-20190222173326-2bc1f35cddc0 does not feel right ;-)

Thanks for your work!

Currently FreeBSD is missing.

Currently all copyright/license information says:
Copyright (c) 2012 The Go Authors. All rights reserved.
You may want to update the year(s) and author(s).

As an aside: Thanks for this library! I've found it pretty handy.

Hi,

See https://beta.golang.org/pkg/os/#Executable

Hi,

When I test your project, I have this error :

command: go test -buildmode pie -compiler gc -ldflags "-X github.com/kardianos/osext/version.commit=ae77be60afb1dcacde03767a8c37337fad28ac14 -X github.com/kardianos/osext/version=0 -extldflags '-Wl,-z,relro '"
testing: github.com/kardianos/osext
github.com/kardianos/osext
--- FAIL: TestExecutableDelete (0.00s)

osext_test.go:135: Child returned "/tmp/go-build341623932/b001/osext.test (deleted)", not the same file as "/tmp/go-build341623932/b001/osext.test"

Thanks

Not much in this package and seems reasonably likely to get into golang. Have you tried?