聊一聊,Golang “相对”路径问题
前言
以 gin-blog 为例,当我们在项目根目录下,执行 [$ 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) ... 那么在不同的目录层级下,不同的方式运行,又是怎么样的呢,带着我们的疑问去学习 问题1、 go run [$ 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 2、 go build,执行 [$ 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 这时候你要打一个大大的问号,就是我的程序读取到什么地方去了 我们通过分析得知, 思考既然已经知道问题的所在点,我们就可以寻思做点什么 : ) 我们想到相对路径是相对执行命令的目录,那么我们获取可执行文件的地址,拼接起来不就好了吗? 实践我们编写获取当前可执行文件路径的方法 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 main.go 2018/03/12 18:45:40 /tmp/go-build962610262/b001/exe 2、 go build $ ./main 2018/03/12 18:49:44 $GOPATH/src/gin-blog 剖析我们聚焦在 在 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. 也就是 因此 这就已经很清楚了,那么我们想想,会出现哪些问题呢
这其实就是根本原因了,因为 解决方案一、获取编译后的可执行文件路径 1、 将配置文件的相对路径与 import ( "path/filepath" "os" "os/exec" "string" ) func GetAppPath() string { file,string(os.PathSeparator)) return path[:index] } 但是这种方式,对于 2、 通过传递参数指定路径,可解决 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" 二、增加 参见 beego 读取 该写法可兼容 三、配置全局系统变量 我们可以通过 1、 设置项目工作区 简单来说,就是设置项目(应用)的工作路径,然后与配置文件、日志文件等相对路径进行拼接,达到相对的绝对路径来保证路径一致 参见 gogs 读取 2、 利用系统自带变量 简单来说就是通过系统自带的全局变量,例如 这样子就能更加固定的存放配置文件,不需要额外去设置一个环境变量 (这点今早与一位SFer讨论了一波,感谢) 拓展
需要注意的是,如果采用获取外部参数的办法,用 小结这三种解决方案,在目前可见的开源项目或介绍中都能找到这些的身影 优缺点也是显而易见的,我认为应在不同项目选定合适的解决方案即可 建议大家不要强依赖读取配置文件的模块,应当将其“堆积木”化,需要什么配置才去注册什么配置变量,可以解决一部分的问题 大家又有什么想法呢,在SF 这里 讨论一波? (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |