I have a golang code on Linux VM which I am remotely debugging using VS Code. Below is my folder structure
MainFolder
|__Config
|__Other folders
Other Files
When I run the code using VS debugger, it runs properly and my code is able to find the path to files. But when I use the terminal to the code (I have workspace configured and need other project to run, and one project to debug) using go run ./folder, it gives some path like /tmp/go-build2342342342/b001/ when absolute path is populated. Any idea why it works this way and how to make the behavior consistent for properly getting the path?
Below is the code converting relative path to absolute
dir, err := filepath.Abs(filepath.Dir(os.Args[0]))
if err != nil {
log.Fatal(err)
}
var path = filepath.Join(dir, relPath)
absPath, err := filepath.Abs(path)
Go binaries are compiled, even when run via go run. When you go run a package, os.Args[0] is set to the path of the compiled binary within the build cache, not the directory containing the source code for that binary.
To determine the path to source files, you must either pass the source location explicitly (as a flag or explicit argument), or invoke go run in a well-known directory and use os.Getwd to located it.
However, for run-time debugging information specifically, see the runtime and runtime/debug packages.
Related
I'm trying to configure a debugger for my project.
Here is the problem.
The project folder structure can be simplified like this:
- Project Root
- X
- Y
- etc
I absolutely need to set the cwd in the debugger config as X, otherwise the binary won't run. If I set it as X, program runs, debugger (sort of) works: I see the call stack and the values of the variables. However, vscode cannot find the files with code and I can't see the lines being executed. VSCode also gives me an error:
Unable to open 'file.cpp':
Unable to read file '/blahblah/cwd/Y/file.cpp'
Error: unable to resolve non-existing file.
So the debugger rightfully uses the cwd as a prefix to the rest of the file path, but Y is not nested into X, it is actually in the same root directory.
Again, I absolutely need the binary to be called from the X directory. Is there any way to tell vscode the proper path to the code files in this case?
So here is what worked for me:
// added this to launch.json
"sourceFileMap: {
"proc/self/cwd" : "{workspaceFolder}"
}
From the VSCode docs:
sourceFileMap:
This allows mapping of the compile-time paths for source
to local source locations. It is an object of key/value pairs and will
resolve the first string-matched path. (example: "sourceFileMap": {
"/mnt/c": "c:\" } will map any path returned by the debugger that
begins with /mnt/c and convert it to c:\. You can have multiple
mappings in the object but they will be handled in the order
provided.)
My problem was that the directory from which I needed the process to run didn't match the directory where the source files are located. In the error message vscode gave me I saw the path it uses to try to find source files ("/proc/self/cwd"). So I mapped this path to the one I actually need (just the workspaceFolder in my case).
So I have a pretty basic configuration with Viper reading a .env file from my base directory. I fatal kill the process if there's no .env file. All goes well when running my app normally.
When I run my tests with go test -v ./.., the test framework seems to step into each file's directory, and calls my config init() function each time, so the viper.AddConfigPath(".") is pointing to the wrong location.
this is my directory structure:
/
/restapi
items.go
items_test.go
/util
env.go
main.go
.env
env.go
package util
imports...
// global variables available via util package
var (
Port int
DbURI string
)
func init() {
viper.SetDefault(PORT, 8080)
viper.SetConfigFile(".env")
viper.AddConfigPath(".")
viper.AutomaticEnv()
fmt.Println("---------to see in test printout")
cwd, _ := os.Getwd()
fmt.Println(cwd)
fmt.Println("---------")
if err := viper.ReadInConfig(); err != nil {
log.Fatal("no environment file!")
}
Port = viper.GetInt("PORT")
DbURI = viper.GetString("DB_URI")
}
Every package basically relies on my util package and this init function therefore runs for every test. Is there some way to have viper always pull the .env file from the base directory even when there are tests running? I've tried a few different AddConfigPath() calls. Kinda new to Go. Or is this structure setup for environment variables not going to work since it fails my tests each time?
So apparently the viper.SetConfigFile() call does not respect the viper.AddConfigPath() call... I modified this to using viper.SetConfigName(".env") and it would actually pick up the calls to AddConfigPath, so I could then add config paths for the current directory and parent.
The problem is the path you are giving to the viper.AddConfigPath(".") method, but your env file relative path is not on the test file based on the folder structure tree you shared, it must be this: viper.AddConfigPath("./../util").
I have an application which is developed in Go. I have a config.env file and get some critical variables from it by using the godotenv library. Here is the code:
func InitializeEnvVars() error {
err := godotenv.Load("./config.env")
return err
}
When I build my project with go build . on MacOS and I want to run the application, the app gives an error about reading the .env file:
2021/03/07 17:42:21 [ERROR]: Error loading .env file
But when I run my app with go run main.go command, everything works well.
How can I solve this problem?
As per the comments godotenv.Load("./config.env") will attempt to load the .env file from the working directory. The method used to set the working directory depends upon how you are starting the application (i.e. command line/gui).
If you would prefer that the .env be loaded from the folder holding the executable then try the following (note that there are some caveats).
ex, err := os.Executable()
if err != nil {
panic(fmt.Sprintf("Failed to get executable path: %s", err))
}
envPath := filepath.Join(filepath.Dir(ex), ".env")
err = godotenv.Load(envPath)
You can find the solution below step by step:
Create a folder like cmd
Move executable file to the folder
Create env file with written named in the code into this folder
Open terminal (zsh - MacOS) and run this command: open <executableFileName>
Output file should be in separated folder.
I have a Go project with the following structure and Im struggling to read config file which is located in my project,I need to read the config yaml (which inside the root project) and I should read it inside other package under sub root directory and I got error of not found
myproject
- config.yaml
- cmd
--com
---ftp
----fs.go
Inside the fs.go I need to read the config.yaml and in not having success with it. I try with os.Getwd and also ex, err := os.Executable() and also "../../../" without success, any idea ?
#VonC - suggested to use https://github.com/gobuffalo/packr which can help I guess but the problem is that I need to call it inside the fs.go file and I need to pass this as parameter from the main.go file, is there a better approach ? because I need to pass this parameter in lots of functions...
does viper can help? https://github.com/spf13/viper
My program is CLI program which will be used as bin.
2018: If the binary is built in GOPATH/bin, while your sources are in GOPATH/src, then the relative path would be (at runtime) ../src/myproject.
But a cleaner way would be to embed that file in your binary.
See for instance gobuffalo/packr.
Update Q1 2021: with Go 1.16, you would use the embed package
Go source files that import "embed" can use the //go:embed directive to initialize a variable of type string, []byte, or FS with the contents of files read from the package directory or subdirectories at compile time.
//go:embed hello.txt
var f embed.FS
data, _ := f.ReadFile("hello.txt")
print(string(data))
In my Go Project I use a function that opens a specific file and returns its content. The file is stored in another directory but still inside my project directory.
package infrastructure
func openKey() ([]byte, error) {
if path, err := filepath.Abs("../security/key.rsa"); err != nil {
return nil, err
}
return ioutil.ReadFile(path)
}
This function works if I call it from a unit test. But if I call the same function in my program, I've this error:
2015/08/13 15:47:54 open
/me/go/src/github.com/myaccount/security/key.rsa: no such file
or directory
The correct absolute path of the file is:
/me/go/src/github.com/myaccount/myrepo/security/key.rsa
Both code that use the openKey function (from my program and unit test) are in the same package: infrastructure
Here is how I execute my program:
go install && ../../../../bin/myproject
And how I execute my unit tests:
go test ./...
And finally the directory structure of my project:
go/src/github.com/myaccount/myrepo/:
- main.go
- security:
- key.rsa // The file that I want to open
- ...
- infrastructure
- openFile.go // The file with the func `openKey``
- server.go // The file with the func that call the func `openKey`
- openFile_test.go // The unit test that calls the func `openKey`
Edit:
Here are the absolute paths of where the binary of my program is located:
/Users/me/Documents/DeĢveloppement/Jean/go/bin
And where my unit tests are located:
/var/folders/tj/8ywtc7pj3rs_j0y6zzldwh5h0000gn/T/go-build221890578/github.com/myaccount/myrepo/infrastructure/_test
Any suggestion?
Thanks!
First, you shouldn't use the same files when running your tests than when running your application in production. Because the test files are accessible to everyone that has access to the repository, which is a security fail.
As said in the comments, the problem is that when running your tests, the working directory is these of the source code (in fact, go copy the whole bunch into a temp directory prior to running the tests), while when you run the program for real, the working directory is the one you are running the command from, hence the wrong relative path.
What I would advise is to use a configuration option to get a the file from which load your file (or a base directory to use with your paths). Either using an environment variable (I strongly encourage you to do that, see the 12factors manofesto for details), a configuration file, a command-line flag, etc.
The go test ./... command changes the current directory to go/src/github.com/myaccount/myrepo/infrastructure before running the tests in that directory. So all relative paths in the tests are relative to the infrastructure directory.
A simple, robust way to allow testing would be to change the signature of your function.
func openKey(relPath string) ([]byte, error) {
if path, err := filepath.Abs(relPath); err != nil {
return nil, err
}
return ioutil.ReadFile(path)
}
This gives you freedom to place key.rsa anywhere during testing, you can for example make a copy of it and store it in infrastructure
An even more elegant and robust way would be to use io.Reader
func openKey(keyFile io.Reader) ([]byte, error) {
return ioutil.ReadAll(keyFile)
}
since you can pass it a strings.Reader for testing. This means that you can test your code without having to rely on the filesystem at all. But that's probably overkill in this case.