原文地址:聊一聊,Golang “相对”路径问题html
Golang
中存在各类运行方式,如何正确的引用文件路径成为一个值得商议的问题git
以 gin-blog 为例,当咱们在项目根目录下,执行 go run main.go
时可以正常运行(go build
也是正常的)github
[$ gin-blog]# go run main.go [GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production. - using env: export GIN_MODE=release - using code: gin.SetMode(gin.ReleaseMode) [GIN-debug] GET /api/v1/tags --> gin-blog/routers/api/v1.GetTags (3 handlers) ...
那么在不一样的目录层级下,不一样的方式运行,又是怎么样的呢,带着咱们的疑问去学习golang
一、 go run
咱们上移目录层级,到 $GOPATH/src
下,执行 go run gin-blog/main.go
segmentfault
[$ src]# go run gin-blog/main.go 2018/03/12 16:06:13 Fail to parse 'conf/app.ini': open conf/app.ini: no such file or directory exit status 1
二、 go build,执行 ./gin-blog/main
api
[$ src]# ./gin-blog/main 2018/03/12 16:49:35 Fail to parse 'conf/app.ini': open conf/app.ini: no such file or directory
这时候你要打一个大大的问号,就是个人程序读取到什么地方去了app
咱们经过分析得知,Golang
的相对路径是相对于执行命令时的目录;天然也就读取不到了学习
既然已经知道问题的所在点,咱们就能够寻思作点什么 : )测试
咱们想到相对路径是相对执行命令的目录,那么咱们获取可执行文件的地址,拼接起来不就行了吗?ui
咱们编写获取当前可执行文件路径的方法
import ( "path/filepath" "os" "os/exec" "string" ) func GetAppPath() string { file, _ := exec.LookPath(os.Args[0]) path, _ := filepath.Abs(file) index := strings.LastIndex(path, string(os.PathSeparator)) return path[:index] }
将其放到启动代码处查看路径
log.Println(GetAppPath())
咱们分别执行如下两个命令,查看输出结果
一、 go run
$ go run main.go 2018/03/12 18:45:40 /tmp/go-build962610262/b001/exe
二、 go build
$ ./main 2018/03/12 18:49:44 $GOPATH/src/gin-blog
咱们聚焦在 go run
的输出结果上,发现它是一个临时文件的地址,这是为何呢?
在go help run
中,咱们能够看到
Run compiles and runs the main package comprising the named Go source files. A Go source file is defined to be a file ending in a literal ".go" suffix.
也就是 go run
执行时会将文件放到 /tmp/go-build...
目录下,编译并运行
所以go run main.go
出现/tmp/go-build962610262/b001/exe
结果也不奇怪了,由于它已经跑到临时目录下去执行可执行文件了
这就已经很清楚了,那么咱们想一想,会出现哪些问题呢
go run
和 go build
不同,一个到临时目录下执行,一个可手动在编译后的目录下执行,路径的处理方式会不一样go run
,不断产生新的临时文件这其实就是根本缘由了,由于 go run
和 go build
的编译文件执行路径并不一样,执行的层级也有可能不同,天然而然就出现各类读取不到的奇怪问题了
1、获取编译后的可执行文件路径
一、 将配置文件的相对路径与GetAppPath()
的结果相拼接,可解决go build main.go
的可执行文件跨目录执行的问题(如:./src/gin-blog/main
)
import ( "path/filepath" "os" "os/exec" "string" ) func GetAppPath() string { file, _ := exec.LookPath(os.Args[0]) path, _ := filepath.Abs(file) index := strings.LastIndex(path, string(os.PathSeparator)) return path[:index] }
可是这种方式,对于go run
依旧无效,这时候就须要2来补救
二、 经过传递参数指定路径,可解决go run
的问题
package main import ( "flag" "fmt" ) func main() { var appPath string flag.StringVar(&appPath, "app-path", "app-path") flag.Parse() fmt.Printf("App path: %s", appPath) }
运行
go run main.go --app-path "Your project address"
2、增长os.Getwd()
进行多层判断
参见 beego 读取 app.conf
的代码
该写法可兼容 go build
和在项目根目录执行 go run
,可是若跨目录执行 go run
就不行
3、配置全局系统变量
咱们能够经过os.Getenv
来获取系统全局变量,而后与相对路径进行拼接
一、 设置项目工做区
简单来讲,就是设置项目(应用)的工做路径,而后与配置文件、日志文件等相对路径进行拼接,达到相对的绝对路径来保证路径一致
参见 gogs 读取GOGS_WORK_DIR
进行拼接的代码
二、 利用系统自带变量
简单来讲就是经过系统自带的全局变量,例如$HOME
等,将配置文件存放在$HOME/conf
或/etc/conf
下
这样子就能更加固定的存放配置文件,不须要额外去设置一个环境变量
(这点今早与一位SFer讨论了一波,感谢)
go test
在一些场景下也会遇到路径问题,由于go test
只可以在当前目录执行,因此在执行测试用例的时候,你的执行目录已是测试目录了
须要注意的是,若是采用获取外部参数的办法,用 os.args
时,go test -args
和 go run
、go build
会有命令行参数位置的不一致问题
这三种解决方案,在目前可见的开源项目或介绍中都能找到这些的身影
优缺点也是显而易见的,我认为应在不一样项目选定合适的解决方案便可
建议你们不要强依赖读取配置文件的模块,应当将其“堆积木”化,须要什么配置才去注册什么配置变量,能够解决一部分的问题
你们又有什么想法呢,在SF 这里 讨论一波?