Python中sys.executable和sys.version之间的不匹配 [英] Mismatch between sys.executable and sys.version in Python

问题描述

安装了两个Python解释器：

There are two Python interpreters installed:

[user@localhost ~]$ /usr/bin/python -V && /usr/local/bin/python -V
Python 2.4.3
Python 2.7.6

Sudo更改 PATH 为其运行的每个命令如下：

Sudo changes PATH for every command it runs as follows:

[user@localhost ~]$ env | grep PATH && sudo env | grep PATH
PATH=/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/user/bin
PATH=/usr/bin:/bin

我运行测试脚本：

[user@localhost ~]$ cat what_python.py
#!/usr/bin/env python

import sys
print sys.executable
print sys.version
[user@localhost ~]$ sudo python what_python.py
/usr/bin/python
2.7.6 (default, Feb 27 2014, 17:05:07) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)]

，并在 sys.executable 中获取Python 2.4.3的路径，并在 sys中报告版本2.7.6。版本。显然 sys.executable 和 sys.version 不匹配。考虑到sudo如何修改PATH，我可以理解 sys.executable 的值。但是，为什么 sys.version 报告版本2.7.6而不是版本2.4.3，这将匹配 usr / bin / python sys.executable 报告

and get path to Python 2.4.3 in sys.executable and version 2.7.6 reported in sys.version. Clearly sys.executable and sys.version do not match. Taking into account how sudo modifies PATH I can understand the value of sys.executable. However, why does sys.version report version 2.7.6 and not version 2.4.3, which would match usr/bin/python path reported by sys.executable?

这是对我的问题的追踪 Sudo更改PATH，但执行相同的二进制

This is a follow-up to my question Sudo changes PATH, yet executes the same binary

推荐答案

两个@Graeme

python可能无法检索这个事实表明它的
正在做自己的PATH搜索（...）

The fact that python may be unable to retrieve this suggests that it is doing its own PATH search (…)

和@twalberg

and @twalberg

（...）它看起来像sys.executable搜索当前PATH而不是
解析argv [0]（或者也许因为argv [0]是这个
案例中的simpy python ... ），（...）

(…) it looks like sys.executable searches the current PATH instead of resolving argv[0] (or maybe because argv[0] is simpy python in this case...), (…)

基本正确。我不太相信Python会像使用 PATH 找到自己的东西那么简单（愚蠢的），但这是真的。

were basically right. I was reluctant to believe that Python does something so simple (silly?) as using PATH to locate itself but this is true.

Python的 sys 模块在 Python / sysmodule.c 文件中实现。从版本2.7.6起， sys.executable 设置在 1422 像这样：

Python's sys module is implemented in Python/sysmodule.c file. As of version 2.7.6, sys.executable is set at line 1422 like this:

 SET_SYS_FROM_STRING("executable",
                     PyString_FromString(Py_GetProgramFullPath()));

Py_GetProgramFullPath（）函数在文件中定义 modules / getpath.c 从行开始 701 ：

Py_GetProgramFullPath() function is defined in file Modules/getpath.c starting from line 701:

char *
Py_GetProgramFullPath(void)
{
    if (!module_search_path)
        calculate_path();
    return progpath;
}

功能 calcuate_path（）在同一个文件中定义，并包含以下 comment < a>：

Function calcuate_path() is defined in the same file and contains the following comment:

/* If there is no slash in the argv0 path, then we have to
 * assume python is on the user's $PATH, since there's no
 * other way to find a directory to start the search from.  If
 * $PATH isn't exported, you lose.
 */

从我的例子可以看出，当第一个Python导出的 $ PATH 与正在运行的Python不同。

As can be seen in my case, one loses also when the first Python on exported $PATH is different than the Python being run.

有关计算解释器的位置过程的更多信息可执行文件可以在顶部 getpath.c 文件：

More information on the process of calculating placement of interpreter's executable can be found at the top of getpath.c file:

在任何搜索完成之前，可执行文件的位置
确定。如果argv [0]中有一个或多个斜线，则使用
不变。否则，它必须从shell的路径
调用，所以我们搜索$ PATH命名的可执行文件并使用它。如果在$ PATH上找不到
可执行文件（或没有$ PATH环境
变量），则使用原始的argv [0]字符串。

Before any searches are done, the location of the executable is determined. If argv[0] has one or more slashes in it, it is used unchanged. Otherwise, it must have been invoked from the shell's path, so we search $PATH for the named executable and use that. If the executable was not found on $PATH (or there was no $PATH environment variable), the original argv[0] string is used.

接下来，检查可执行位置以查看它是否是符号
链接。如果是这样，链接被追踪（正确地解释一个相对的
路径名，如果找到）和链接目标的目录。

Next, the executable location is examined to see if it is a symbolic link. If so, the link is chased (correctly interpreting a relative pathname if one is found) and the directory of the link target is used.

让我们进行一些测试来验证以上内容：

Let's make a couple of tests to verify the above:

如果argv [0]中有一个或多个斜线，则使用它

If argv[0] has one or more slashes in it, it is used unchanged.

[user@localhost ~]$ sudo /usr/local/bin/python what_python.py
/usr/local/bin/python
2.7.6 (default, Feb 27 2014, 17:05:07) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)]

Ok。

如果在$ 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模块的文档的声明是真的 - 如果Python无法检索其可执行文件的真实路径，sys.executable将是一个空字符串或无。。

Wrong. In this case statement from sys module's documentation is true – If Python is unable to retrieve the real path to its executable, sys.executable will be an empty string or None. .

我们来看看如果添加python的二进制位置回到 PATH （在sudo已经删除之后）修复问题：

Let's see if adding location of python's binary back to the PATH (after sudo had removed it) fixes the problem:

[user@localhost ~]$ sudo PATH=$PATH python what_python.py
/usr/local/bin/python
2.7.6 (default, Feb 27 2014, 17:05:07) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)]

它是。

相关：

• Python问题 7774 - sys.executable：如果修改了zeroth命令参数，错误的位置。


• Python问题 10 835 - sys.executable default and altinstall


• python-dev邮件列表线程 - 朝向更严格的sys.executable定义


• Stackoverflow 问题 - 如何在C中找到可执行文件的位置

• Python issue 7774 – sys.executable: wrong location if zeroth command argument is modified.
• Python issue 10835 – sys.executable default and altinstall
• python-dev mailing list thread – towards a stricter definition of sys.executable
• Stackoverflow question – how to find the location of the executable in C

这篇关于Python中sys.executable和sys.version之间的不匹配的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！