python - 直接调用与 Python 子进程时 GOPATH 的解释不同

Question

我最近发现了 Python getpass 无法在 Windows 上运行的修复:Python not working in the command line of git bash

或者至少那是我记得的关于更改 Python 配置的最后一件事。 (这是针对 Windows 10 上的 Python 3.6.1)

现在我也将 Python 用于其他任务，这些任务只需调用子进程以在终端上键入多个命令:

go build ./folder/
mv ./src/ ./bin/

我收到错误:go: GOPATH entry is relative;必须是绝对的:“/c/Users/OP/work”。但是，如果我自己输入 go build ./src/folder，我就无法理解。 我在环境变量中将 GOPATH 设置为 C:\work。我试过使用 ;。

有没有办法每次都反转别名python？或者将 python 的别名设置为 winpty 时到底发生了什么？

我在想，当我直接调用 go build 时，它是由我的用户配置文件或系统调用的。而当python的subprocess调用它的时候，它调用的是相反的。因此，即使我在环境变量中只设置了 1 个，我也有两个 GOPATH 变量。

旁注:最近对 GOPATH 的另一个更改是从 C:/go 更改它，因为它不能与 GOROOT 相同。由于某种原因，该错误随机弹出。它使用该设置工作了一段时间，我不记得之前更改过任何内容，只是在许多其他已经使用的导入包之上添加了另一个导入包。

更新:使用 type python 我得到结果:python 的别名是“winpty python.exe”。因此，我尝试使用 unalias python 撤消它。我得到的新结果是:python is hashed (/c/Users/OP/AppData/Local/Programs/Python/Python36/python)。

这修复了 Python 子进程中的 go build 命令。但是，该别名修复了使用 getpass 包时出现的另一个 Python 问题。

Answer 1

除了我的 unalias python 修复之外，我还发现了一些有趣的事情:当我将 GOPATH 的环境变量从 C:\work; 更改为 C 时:\go，所有go命令仍然会报错go: GOPATH entry is relative;必须是绝对的:“”。我在更新 Windows 10 时遇到了同样的错误(但路径不同)Fall Creators更新。也许是相关的。

只需关闭 MINGW 并重新打开它即可解决问题。所以也许它是在说我的环境变量的副本并将其用作引用而不是实际的系统属性。

我知道这不是一个热门问题，但有人可以从我的调查和调试时间中获益。