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

Failed to run 'usr/local/go/bin/go env: Error: spawn usr/local/go/bin/go ENOENT #667

Closed
yihanzhen opened this issue Sep 19, 2020 · 10 comments

Comments

@yihanzhen
Copy link

What version of Go, VS Code & VS Code Go extension are you using?

  • Run go version to get version of Go
    • go version go1.13.5 darwin/amd64
  • Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders
    • 1.47.3
  • Check your installed extensions to get the version of the VS Code Go extension
    • 0.17.0
  • Run go env to get the go development environment details
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/[myusername]/Library/Caches/go-build"
GOENV="/Users/[myusername]/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/[myusername]/codefolder/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/path/to/my/project/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/r9/1ys7ns3x1ybfcrgwsz6_5pnw0000gn/T/go-build063456075=/tmp/go-build -gno-record-gcc-switches -fno-common"

Share the Go related settings you have added/edited

Default settings.

Describe the bug

Whenever editing a Go file, there is such an error in the output:

Failed to run 'usr/local/go/bin/go env: Error: spawn usr/local/go/bin/go ENOENT

It seems like the absolute path got resolved to relative path incorrectly.

Switching back to 0.16.0 resolves the issue.

Screenshots or recordings

image

@hyangah
Copy link
Contributor

hyangah commented Sep 21, 2020

@yihanzhen Can you please share the output of Go: Locate Configured Go Tools command with 0.16.x and also with 0.17.0 if possible?

I think the relevant change is #555 - previously, the extension silently failed to work correctly but now it surfaces the failure. However, there could be other bugs.

@yihanzhen
Copy link
Author

Hey @hyangah thanks for the reply!

Yep your analysis sounds right. My PATH envvar was corrupted with a usr/local/go/bin entry. When running go tools from command line directly everything was fine because OS will just continues after this path entry and find the go binary. The vscode extension decided to stop right there when it sees usr/local/go/bin, although it was invalid.

Anyway I got what I want (and lots of thanks!), feel free to close this issue or leave if open to track any potential improvements you may want to make.

@rifqimf12
Copy link

hi @yihanzhen, can you elaborate what you mean by:

My PATH envvar was corrupted with a usr/local/go/bin entry.

and step you take to get it fix?
i had the same issue too, and now i'm using 0.16.x to get it work again.

@yihanzhen
Copy link
Author

@Rifqi12 so I had something like this in my bash file:

export PATH=$PATH:usr/local/go/bin

which was wrong and should have been:

export PATH=$PATH:/usr/local/go/bin

Fixing that resolved the issue for me.

@gopherbot
Copy link
Collaborator

Change https://golang.org/cl/256557 mentions this issue: src/goLogging.ts: add go.logging.level and log PATH mutation

gopherbot pushed a commit that referenced this issue Sep 24, 2020
go.logging.level determines the extension's debug logging level.
Currently, all log messages go to console.log. Eventually, we
will want to provide an option to output in an OUTPUT channel
or a file.

Add verbose logging to trace how the current GOROOT is determined
and how PATH is mutated.

Update #667

Change-Id: I95275ee4843d6cc9f8e34367f832a728ac1ea63f
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/256557
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Suzy Mueller <suzmue@golang.org>
@ahmetb
Copy link

ahmetb commented Dec 26, 2020

Hi folks, I'm also getting an error like this. To me, VSCode for Mac works fine, however if the IDE is loaded in the browser via the code-server that runs on the same machine, it gives an error.

In my case, I think the culprit is basically that code-server runs as a system daemon (brew services start code-server) without my usual $PATH variable ––and my VSCode toolsGopath path is customized (to /Users/ahmetb/gotools), which is no longer in $PATH.

Here's the Locate Configured Go tools output from code-server UI:

Checking configured tools....
GOBIN: undefined
toolsGopath: 
gopath: undefined
GOROOT: 
PATH: /usr/local/opt/node/bin:/usr/bin:/bin:/usr/sbin:/sbin

failed to run "/usr/local/go/bin/go version": Error: spawn /usr/local/go/bin/go ENOENT cwd: /Users/ahmetb/workspace/runstatic

And here's my Locate Configured Go tools output from VSCode for MacOS (which doesn't work):

output
Checking configured tools....
GOBIN: undefined
toolsGopath: /Users/ahmetb/gotools
gopath: /Users/ahmetb/go
GOROOT: /usr/local/Cellar/go/1.15.6/libexec
PATH: /Users/ahmetb/go/bin:/Users/ahmetb/.krew/bin:/Users/ahmetb/workspace/dotfiles/bin:/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin:/usr/local/opt/python/libexec/bin:/usr/local/opt/openssl/bin:/usr/local/opt/gettext/bin:/usr/local/opt/gnu-time/libexec/gnubin:/usr/local/opt/grep/libexec/gnubin:/usr/local/opt/gnu-sed/libexec/gnubin:/usr/local/opt/gnu-tar/libexec/gnubin:/usr/local/opt/gnu-indent/libexec/gnubin:/usr/local/opt/gnu-getopt/bin:/usr/local/opt/coreutils/libexec/gnubin:/usr/local/bin:/usr/local/sbin:/usr/local/git/current/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/Applications/Wireshark.app/Contents/MacOS:/Users/ahmetb/gotools/bin:/usr/local/opt/fzf/bin:/Users/ahmetb/google-cloud-sdk/bin:/Users/ahmetb/Library/Application Support/cloud-code/installer/google-cloud-sdk/bin

gopkgs: /Users/ahmetb/gotools/bin/gopkgs installed
go-outline: /Users/ahmetb/gotools/bin/go-outline installed
gotests: /Users/ahmetb/gotools/bin/gotests installed
gomodifytags: /Users/ahmetb/gotools/bin/gomodifytags installed
impl: /Users/ahmetb/gotools/bin/impl installed
goplay: /Users/ahmetb/gotools/bin/goplay installed
dlv: /Users/ahmetb/gotools/bin/dlv installed
golint: /Users/ahmetb/gotools/bin/golint installed
gopls: /Users/ahmetb/gotools/bin/gopls installed

go env
Workspace Folder (runstatic): /Users/ahmetb/workspace/runstatic
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/ahmetb/Library/Caches/go-build"
GOENV="/Users/ahmetb/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/ahmetb/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/ahmetb/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.15.6/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.15.6/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/ahmetb/workspace/runstatic/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/9h/97gkgcl96vz3vvb9v52tw3gw00dl55/T/go-build770973503=/tmp/go-build -gno-record-gcc-switches -fno-common"

@hyangah
Copy link
Contributor

hyangah commented Dec 28, 2020

@ahmetb I think the bug #1065 caused confusion here (sorry for the regression and I hope to release a fix soon) The real culprit in your case is, as you already explained, bre services start code-server launched the code-server without the usual $PATH variable. The extension (that runs on the code-server side) searches PATH and a couple of extra places (configured with "go.goroot" or "go.alternateTools" ) to find the go binary.

@g-a-c
Copy link

g-a-c commented Feb 19, 2021

@ahmetb
failed to run "/usr/local/go/bin/go version": Error: spawn /usr/local/go/bin/go ENOENT cwd: /Users/ahmetb/workspace/runstatic

I know this is an old issue but I've just come across the same error, and found that one of the root directories in my workspace had been removed from the filesystem, without also being removed from the workspace.

Given the cwd: part of your error message, I would check that directory still exists, and either create it or remove it from your workspace

@gopherbot gopherbot added this to the Untriaged milestone Apr 8, 2021
@stamblerre
Copy link
Contributor

Closing, as this issue hasn't had any activity for a few months.

@stamblerre stamblerre removed this from the Untriaged milestone Apr 9, 2021
@kay-haensge
Copy link

@ahmetb failed to run "/usr/local/go/bin/go version": Error: spawn /usr/local/go/bin/go ENOENT cwd: /Users/ahmetb/workspace/runstatic

I know this is an old issue but I've just come across the same error, and found that one of the root directories in my workspace had been removed from the filesystem, without also being removed from the workspace.

Given the cwd: part of your error message, I would check that directory still exists, and either create it or remove it from your workspace

This was also my problem. Thanks!! You saved my day!

@golang golang locked and limited conversation to collaborators Jan 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants