都@Graeme
python可能无法检索到它的事实表明它正在做自己的PATH搜索（…）
和@twalberg
（…）看起来sys.executable会搜索当前的PATH，而不是解析argv [0]（或者可能是因为argv [0]在这种情况下是simpy
python …），（…）
基本上是正确的。我不愿意相信Python做的事情很简单（愚蠢？），就像
PATH用来定位自己一样，但这是事实。
Python的
sys模块在
Python/sysmodule.c文件中实现。从版本2.7.6开始，
sys.executable在第1422行设置如下：
SET_SYS_FROM_STRING("executable", PyString_FromString(Py_GetProgramFullPath()));Py_GetProgramFullPath()函数在
Modules/getpath.c第701行开始的文件中定义：
char *Py_GetProgramFullPath(void){ if (!module_search_path) calculate_path(); return progpath;}函数
calcuate_path()在同一文件中定义，并包含以下注释：
从我的案例可以看出，当导出的第一个Python
$PATH与正在运行的Python不同时，一个人也会迷失。
关于计算解释的可执行的位置的过程的更多信息可以在找到顶部的
getpath.c文件：
在执行任何搜索之前，必须确定可执行文件的位置。如果argv
[0]中包含一个或多个斜杠，则将其原样使用。否则，必须已经从外壳程序的路径中调用了它，因此我们在$ PATH中搜索命名的可执行文件并使用它。如果在$
PATH上找不到可执行文件（或没有$ PATH环境变量），则使用原始argv [0]字符串。接下来，检查可执行位置以查看它是否是符号链接。如果是这样，则跟踪链接（如果找到一个，则正确解释相对路径名），并使用链接目标的目录。
让我们进行一些测试以验证以上内容：
如果argv [0]中包含一个或多个斜杠，则将其原样使用 。
[user@localhost ~]$ sudo /usr/local/bin/python what_python.py/usr/local/bin/python2.7.6 (default, Feb 27 2014, 17:05:07) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)]
好。
如果在$ PATH上找不到可执行文件（或没有$ PATH环境变量），则使用原始argv [0]字符串。
[user@localhost ~]$ sudo PATH= python what_python.py<empty line>2.7.6 (default, Feb 27 2014, 17:05:07) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)]
错误。在这种情况下，sys模块文档中的声明为true –
如果Python无法检索其可执行文件的真实路径，则sys.executable将为空字符串或None。 。
让我们看看将python二进制文件的位置添加回
PATH（在sudo删除后）是否 解决 了问题：
[user@localhost ~]$ sudo PATH=$PATH python what_python.py/usr/local/bin/python2.7.6 (default, Feb 27 2014, 17:05:07) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)]
是的
有关：
- Python问题7774 – sys.executable：如果修改了第零个命令参数，则位置错误。
- Python问题10835 – sys.executable默认值和altinstall
- python-dev邮件列表线程–更严格的sys.executable定义
