问题

为什么 macOS 在 /usr/bin/ 下会有 python3?

回答
macOS 在 `/usr/bin/` 目录下放置 `python3`,这并非偶然,而是系统设计和历史演进共同作用的结果。要理解这一点,我们需要从几个层面来剖析。

1. 系统自带与包管理工具的共存

macOS,和其他许多类 Unix 系统一样,在 `/usr/bin/` 目录下存放着大量系统核心工具和命令。这些工具是操作系统正常运行所必需的,也是用户进行命令行操作的基础。

系统完整性(System Integrity Protection SIP):现代 macOS 版本引入了 SIP,旨在保护系统关键目录(包括 `/usr/bin/`)中的文件不被未经授权的修改。这意味着,直接修改 `/usr/bin/` 目录下的文件,即使是管理员权限,也通常是不被允许的。`/usr/bin/` 下的文件通常由 Apple 负责管理和更新。
默认 Python 环境:Apple 确实会在 macOS 系统中预装一个 Python 版本,并且这个预装的版本通常会链接到 `/usr/bin/python3`。这个预装的 Python 是为了满足系统自身需求,以及为那些不打算或不方便安装第三方包管理工具(如 Homebrew)的用户提供一个基础的 Python 运行环境。
第三方包管理器(如 Homebrew):然而,对于大多数开发者来说,`/usr/bin/` 下的系统自带 Python 并不是首选。原因有几点:
版本控制:不同项目可能需要不同版本的 Python。系统自带的 Python 版本相对固定,更新周期较长,无法满足开发者对新特性或特定版本兼容性的需求。
包管理:系统自带 Python 并不自带 `pip`(Python 包管理器),或者即使有,也可能与系统其他部分产生冲突。开发者通常依赖 `pip` 来安装各种第三方库。
隔离性:将开发用的 Python 环境与系统自带环境隔离,可以避免潜在的依赖冲突,确保系统的稳定性。Homebrew 等工具正是为了解决这个问题而生,它们会将 Python 和相关的库安装在自己管理的目录(例如 `/usr/local/bin/` 或 `/opt/homebrew/bin/`)下,并且通过修改用户的 `$PATH` 环境变量,让系统优先使用这些第三方安装的版本。

2. 历史原因与兼容性

Python 在类 Unix 系统中的普及程度非常高。从 Python 2 到 Python 3 的过渡,也对系统预装的策略产生了一定的影响。

Python 2 的遗留:在过去,许多类 Unix 系统(包括 macOS)会将 `python` 命令指向 Python 2。随着 Python 2 的生命周期结束,系统逐渐将默认的 `python` 命令移除或指向 Python 3,同时提供 `python3` 作为明确的 Python 3 解释器。
标准化:在 `/usr/bin/` 目录下提供 `python3`,也是一种标准化操作。许多脚本和应用程序会直接依赖 `/usr/bin/python3` 来执行,如果这个路径不存在,那么这些脚本和程序就无法正常工作。Apple 这样做是为了确保系统内部以及一些基础的第三方应用程序能够顺利运行。

3. 链接(Symbolic Links)的作用

你看到的 `/usr/bin/python3` 极有可能是一个符号链接(symbolic link)。这意味着它本身并不是 Python 解释器的二进制文件,而是指向系统实际安装的 Python 3 解释器的文件路径。

动态更新:通过符号链接,Apple 可以在不改变 `/usr/bin/python3` 这个固定路径的情况下,更新系统自带的 Python 版本。例如,`/usr/bin/python3` 可能链接到 `/System/Library/Frameworks/Python.framework/Versions/3.X/bin/python3`,其中 `3.X` 代表具体的 Python 版本。当 Apple 更新系统时,他们会更新这个链接指向的实际文件。
版本统一:这也有助于为系统提供一个统一的 Python 3 入口点,而无需关心具体是哪个子版本。

总结来说,macOS 在 `/usr/bin/` 下提供 `python3` 是出于以下几个关键原因:

1. 系统需求:确保操作系统自身以及一些依赖 Python 的系统级工具能够正常运行。
2. 兼容性:为那些依赖 `/usr/bin/python3` 路径的脚本和应用程序提供兼容性。
3. 标准化:遵循类 Unix 系统中将核心工具放置在 `/usr/bin/` 的约定。
4. 管理与更新:通过符号链接的方式,允许 Apple 在不改变标准路径的情况下更新系统自带的 Python 版本,同时保持系统的完整性。

然而,对于开发者而言,强烈建议通过 Homebrew 等第三方包管理器安装和管理自己的 Python 环境,并确保用户的 `$PATH` 环境变量能够正确指向你想要使用的 Python 版本,以避免与系统自带的 Python 发生冲突。

网友意见

user avatar

简略版答案:

题目中的这个 Python 3.8.2 来自于苹果的一套命令行开发者工具(command line developer tools),其对应目录在:

       /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework     

而在终端执行/usr/bin目录下的python3时,终端先根据环境变量PATH扫描是否有 Python 3.x 的可执行程序,若不存在,则调出命令行开发者工具的安装程序,引导用户安装。

命令行开发者工具并不会对从官网下载安装的 Python 有任何影响,并且也不建议开发者删除(因为这也会将gitclanggccflex等工具一并删除)。

只有当并不需要额外的其他工具,并认为此确实困扰到了自己的时候,才可以将其删掉,这个 Python 3.8.2 就随之消失了,执行如下命令即可:

       sudo rm -rf /Library/Developer/CommandLineTools     

(以下为原文)

这个问题提的很好,平常我用 macOS 的时候从未想到会有这个问题。

因为 macOS 是一个类 Unix 系统,系统文件结构与 Linux 类似,以我用 Linux 的经验来看,按理说,/usr/bin目录下的python3是一个链接文件(替身),可以从它找到相应指向的源文件(原身),进而可以得出系统内置 Python 3 所在的目录。

但我用

       cd /usr/bin && ls -la@O | grep python3     

查看了这个文件的属性,却发现“python3”是一个可执行文件:

       -rwxr-xr-x     1 root   wheel  restricted,compressed   137600  1  1  2020 python3     

这确实令我困惑,因为官方的帮助里并没有对这个细节作任何提及,不过我发现这样一个链接——

注意到了这样一句话:

A clean installation of Catalina includes a/usr/bin/python3binary, but it's a stub for installing the command line developer tools, which includes Python 3.

“stub”这个词有“桩脚”的意思,但这里我没能理解,不过我注意到了“clean installation”和“command line developer tools”。

所以可猜:macOS “内置”的 Python 3 很可能与命令行开发者工具有关。

为验证猜想,我从头创建了一个 macOS 虚拟机,当我迫不及待地执行python3这个命令的时候,神奇的一幕出现了:

系统竟然提示我安装命令行开发者工具 (以下简称 CLDT) ?!

安装好后,python3命令可以正常使用了,当然这个版本就是 3.8.2,和题目一模一样。然后开始搜索 Python 3.8.2 的相应资源,结果发现全在这里:

       /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework     

相应的 CLDT 目录在:

       /Library/Developer/CommandLineTools     

接下来删掉 CLDT 的目录(以下就是把它卸载的方法):

       sudo rm -rf /Library/Developer/CommandLineTools     

结果发现删除目录之后python3命令又会失效,回到前面的提示了。

但若从 python.org 安装好 Python,执行python3命令后,其显示的 Python 版本却是已经安装的版本。

所以,这个诡异的执行文件/usr/bin/python3的作用大概可以知道了:单独运行此程序时,调用 CLDT 中的 Python 3,若无 CLDT,且无手动安装的 Python,则激活“Install Command Line Developer Tools”应用,引导用户安装。[1]

可能有人会问了:为什么从终端调用python3命令(而不是手动双击执行那个二进制文件)的时候,就只会运行手动安装的 Python 呢?

原因是环境变量 PATH 默认先加载配置在最前面的路径,如果某命令已经加载完毕,则不再继续往下寻找,否则会继续寻找,直到全部加载为止,若完全找不到,当然会输出“command not found”啦。

比方说我的用户名为administrator(大雾),执行如下命令:

       echo $PATH | awk '{ gsub(/:/,"
"); print $0 }'     

输出结果如下(这就是我的 Mac 上的PATH变量的设定,分行显示的):

       /usr/local/sbin /usr/local/bin /Users/administrator/opt/anaconda3/bin /Library/Frameworks/Python.framework/Versions/3.9/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin /Applications/VMware Fusion.app/Contents/Public /Applications/Server.app/Contents/ServerRoot/usr/bin /Applications/Server.app/Contents/ServerRoot/usr/sbin /Library/Apple/usr/bin /Users/administrator/.cargo/bin     

可以看到/usr/local/bin排在/usr/bin之前。

而我手动安装 Python 3.9.1 后,执行 which python3命令可以看到,python3命令执行的路径则在/usr/local/bin目录下:[2]

       /usr/local/bin/python3     

因此系统只会加载 /usr/local/bin下的 python3。

针对此,我们可以再验证一下:执行

       type -a python3     

来查看依据环境变量PATH下能查找到python3命令的所有执行文件的路径。

比方说在我的 Mac 上的是

       python3 is /usr/local/bin/python3 python3 is /Library/Frameworks/Python.framework/Versions/3.9/bin/python3 python3 is /usr/local/bin/python3 python3 is /usr/bin/python3     

只有排在最前的会首先加载,也就是/usr/local/bin下的python3

苹果的 macOS 开发工程师们明知道大多数用 Python 的用户都会将解释器的目录设置在/usr/local/bin目录下,为何在/usr/bin塞入一个单独的二进制执行文件,而不是链接?

我个人最初觉得,这样设计是为了迎合某些 Linux 用户的编程习惯,因为这些人编写 .py 的脚本的时候,知道 Shell 解释器和一些工具的必需执行文件基本上要放在/usr/bin目录下,会习惯性调用 Linux 内部的 Python,放到 macOS 上也一样。

但这个猜想似乎无法解释的通。后来我在不经意间有了新的发现:谜底竟然藏在xcode-select命令的帮助文件里。[3]

很多使用 Homebrew 的朋友,在首次安装 CLDT 的时候,都用到xcode-select这个命令:

       xcode-select --install     

xcode-select这个命令的主要作用,其实是为了方便开发者在安装了多个版本的 Xcode 下(尤其是安装有 Beta 版本的 Xcode,不在默认安装位置/Applications的时候)切换不同的开发者目录,从而可以用不同版本的 CLDT 通过脚本和 makefile 进行有针对性的编译。

由此设计的/usr/bin/python3这个可执行文件,就是从已经激活的开发者目录里查找并运行相匹配的 Python 版本。

相比 Windows 和某些 GNU/Linux 发行版找不到命令时简单粗暴的“直接报错”,这个让众多用户无法察觉到的设计,才是 macOS 的巧妙所在。

至此,这个问题才算真正解决了。

说真话,整个发现的过程虽然花了我很长的时间,但还是很值得回味的。


针对题主的提问,希望再啰嗦两点——

第一点是 macOS 内置的 Python 2 的消失。

Python 2 的最后一个版本是 2.7.16,已经于 2020 年的头一天就被官方停止支持了,但首次不支持 Python 2 的 macOS 版本是 Monterey 12.3 (21E230)。

对于该版本之前的 macOS,因为 Python 2 依然存在,仍可以用python关键字来调用它。

第一次使用该命令时会显示一个警告:

WARNING: Python 2.7 is not recommended. This version is included in macOS for compatibility with legacy software. Future versions of macOS will not include Python 2.7. Instead, it is recommended that you transition to using 'python3' from within Terminal.
(警告:不推荐使用 Python 2.7。此版本包含在 macOS 中以与旧版软件兼容。未来的 macOS 版本将不再包含 Python 2.7。相反,建议您从终端过渡到使用“python3”。)

以及当安装了旧版的 pip package 时,你会看到如下的信息:

DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
(声明:Python 2.7 将于 2020 年 1 月 1 日到期,请升级您的 Python,因为自此日起将不再维护 Python 2.7。pip 的未来版本将会放弃对 Python 2.7 的支持。)

这说明从 2020 年 1 月 1 日到 2022 年 3 月 16 日 Monterey 12.3 发布的这段时间内,macOS 内置 Python 2 的目的是为了让开发者进行老旧软件的过渡。

但自从 macOS Monterey 12.3 后,Python 2 已从系统中消失,因此只能通过python3命令来调用 Python 3,原有的关键字python不再可用。

如果想经常使用python关键字来调用 Python 3,请首先用 vim 或 nano 编辑~/.zshenv文件(若使用的 Shell 为 Bash 则编辑~/.bash_profile文件);

然后在其中加入如下的一行:

       alias python='python3'     

保存后再执行source ~/.zshenv( 若为 Bash 则执行source ~/.bash_profile) ,重启终端即可生效。

另外需要说明的一点是,macOS 有一个安全机制,即系统完整性保护(System Integrity Protection,SIP),用来保护 macOS 的系统文件不受篡改,当然这个保护可以关闭,但会一定程度上降低 macOS 的安全性。即使关闭了 SIP,/usr/bin目录下的文件仍然不能删除,哪怕 root 用户也不行,因此题主也不可能删得了这个二进制的文件python3

(这个细节也体现了 macOS 系统的健壮性)

✄- - - - - - - - - - - - - - - - -

退一步想,假如/usr/bin下的文件像 Linux 一样可以通过 root 权限删除,那么在运行程序的时候,会导致无法预料的错误,甚至是系统的严重破坏。

Linux 上的sudo rm -rf /*就是一个很惨痛的例子,不光所有的用户文件都会被删除,而且内核依赖的文件也因删除而彻底无法启动系统。

✄- - - - - - - - - - - - - - - - -

然而,对于题主来说,为了去掉这个多余的 Python 3.8.2,最佳的解决方法就是卸载命令行开发者工具,这个方法就在前面说过了。

当然这个问题的解决方案不止一种,比方说可以修改PATH环境变量,或用 Anaconda。

如果你是第一次接触 Anaconda 的话,可以把 Anaconda 的 environment 理解为一个盛装 Python 的容器,而且 Python 的版本可以不同,pip package 则可以单独安装。

不同的是,执行命令

       which python     

时,base 环境下,返回的结果不是系统 Python 2 的解释器目录,而是下面的这个:

       ~/opt/anaconda3/bin/python     

其他创建的环境下则是:

       ~/opt/anaconda3/envs/[自定义环境名]/bin/python     

其中“~”代表你自己的用户文件夹。

python3命令则不受影响。

之前做了一些数据挖掘相关的东西,为了激活不同的环境,我会用 iTerm2 创建不同的配置文件,配合 Anaconda 使用。但比较郁闷的是 Tensorflow 死活配置不好,这一点非常想吐……

最后放一张很有意思的图。

不说了,我先笑一会儿……

参考

  1. ^ 更进一步,为了真实探究这个二进制可执行文件其中的工作原理,就需要借助反汇编了,不过我这里我的能力有限,但从反汇编的内容中看到了四个关键字符串,其中有两个分别是“llvm-gcc”和“clang”,目测与编译器有关。如有擅长逆向工程的高手,可给我补充。
  2. ^ 这是一个替身,它指向的原身为:/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9。链接文件与原文件其实起同等的作用的。
  3. ^ 可以通过使用“man xcode-select”来查看 xcode-select 命令的帮助文件。

类似的话题

  • 回答
    macOS 在 `/usr/bin/` 目录下放置 `python3`,这并非偶然,而是系统设计和历史演进共同作用的结果。要理解这一点,我们需要从几个层面来剖析。 1. 系统自带与包管理工具的共存macOS,和其他许多类 Unix 系统一样,在 `/usr/bin/` 目录下存放着大量系统核心工具和.............
  • 回答
    在 macOS 的平台上,Chrome 和 Safari 在用户体验上的流畅度差异,常常是用户津津乐道的话题。很多人会发现,虽然 Chrome 强大且功能丰富,但在 Mac 上,它的滑动、缩放等操作,有时总感觉不如 Safari 那般“如丝般顺滑”。这其中的缘由,并非单一因素能解释,而是技术实现、底.............
  • 回答
    这个问题很有意思,触及了社区文化、用户群体画像、认知偏差以及技术讨论的本质。我们可以从以下几个方面来详细分析: 一、用户群体画像与情感连接的差异 1. macOS用户:情感认同与身份认同 品牌忠诚度高: macOS用户往往对苹果的产品线(iPhone, iPad, MacBook等)有着较高的品.............
  • 回答
    在电脑操作系统的世界里,macOS 和 Windows 分别代表着两种截然不同的设计哲学和演进路径。当咱们拿这俩玩意儿放在一起比,你会发现 macOS 在很多细节上,似乎“看不见”或者说“刻意规避”了一些在 Windows 上存在了很久、甚至可以说“古老”的设计元素。这倒不是说 macOS 就一定更.............
  • 回答
    这的确是个很有意思且令人费解的现象。很多人都有类似的体验:在 Mac 上跑 Windows 虚拟机(比如通过 Parallels Desktop 或 VMware Fusion)感觉相当流畅,甚至能应对不少日常工作和一些对性能要求不高的游戏。但反过来,想在 Windows PC 上跑 macOS 虚.............
  • 回答
    macOS之所以不需要像Windows那样依赖注册表,主要是因为两者在操作系统设计哲学和文件管理方式上存在根本性的差异。在Windows的世界里,注册表就像一个庞大的中央数据库,存储着系统运行所需的几乎所有信息:硬件配置、软件设置、用户偏好、系统文件关联等等。当你安装一个程序、更改一个系统设置,甚至.............
  • 回答
    一直以来,“macOS鼠标体验差”这个说法,就像个挥之不去的老朋友,时不时就会跳出来被提起。说实话,对于长期使用macOS的用户来说,这种感受确实存在,而且不是空穴来风。要说它“差”,其实有点过于绝对,不如说是在某些方面,它并没有达到很多用户,尤其是习惯了Windows或其他操作系统用户们的预期,甚.............
  • 回答
    苹果在数字内容创作和办公领域确实展现了一种与众不同的商业逻辑,使得macOS、iWork(Pages, Numbers, Keynote)以及iLife(GarageBand, iMovie, Photos)这些核心软件能够以免费的形式提供给用户,这与微软Office等软件的收费模式形成了鲜明对比。.............
  • 回答
    这个问题很有意思,也挺容易让人产生误解的。其实说macOS完全没有盗版,那是不准确的,只是相较于Windows来说,macOS的盗版现象确实不那么普遍,而且传播方式和用户群体也有所不同。我们不妨从几个方面来掰扯掰扯这个现象。首先得说,这俩系统,出身和定位就不一样。苹果的“围墙花园”策略:软硬一体的生.............
  • 回答
    这个问题非常有趣,它触及了用户体验、市场营销、生态系统以及特定用户群体的需求等多个层面。知乎上“macOS 很好用”的说法与实际的市场占有率存在差距,这并非矛盾,而是反映了不同维度上的评价和现实。下面我将详细阐述其中的原因:一、 知乎用户群体的特性:首先,我们需要理解知乎作为一个平台的属性。知乎是中.............
  • 回答
    这其实是一个挺有意思的问题,也是不少人对 Linux 感到好奇的地方。为什么 Linux 这么强大,社区这么活跃,却没像 macOS 和 Windows 那样成为普通用户桌面上的主流呢?咱们掰开了揉碎了好好聊聊。首先得承认,Linux 本身是一个非常优秀的操作系统内核,它的强大和灵活是毋庸置疑的。但.............
  • 回答
    这问题问得挺好,也很实际。15 年前,也就是 2009 年左右,Linux 确实已经是个有模有样的操作系统了,而且开源免费,功能强大,吸引了不少技术爱好者。但即便如此,macOS 依然在市场上占有自己的一席之地,而且说实话,近些年市场份额还有回升的趋势。这背后的原因,我觉得可以从几个方面掰开了聊。首.............
  • 回答
    Windows 与 iOS/macOS 的更新周期差异,本质上是操作系统开发策略、市场需求、技术生态和企业需求等多重因素共同作用的结果。以下从多个维度详细分析这一现象: 1. 操作系统定位与用户群体差异 Windows 是面向桌面和企业用户的核心操作系统,用户群体庞大且需求多样化,包括个人用户、中小.............
  • 回答
    你这个问题问得很有意思,也切中了很多人对Mac的一个普遍看法。说macOS“用的人很少”呢,其实也对,也不全对。咱们得拆开来看。首先,从全球PC市场份额来看,macOS的用户基数确实是小于Windows的。这个数据是客观存在的。你可以看看市面上笔记本电脑的品牌有多少,戴尔、惠普、联想、华硕等等,这些.............
  • 回答
    在国内的服务器操作系统选择上,确实很少见到 macOS Server 的身影。这背后并非偶然,而是多种因素交织作用的结果。要深入理解这一点,我们需要从技术、市场、生态以及国家政策等多个层面来分析。技术层面:并非“一刀切”的完美选择首先得承认,macOS Server 本身并非一无是处。在某些领域,它.............
  • 回答
    不少用户在使用一段时间Windows和macOS后,会产生一个疑问:Windows 真的没有macOS 流畅吗?为什么? 这个问题其实没有一个绝对的答案,因为“流畅”本身是一个主观感受,而且影响因素非常多。但我们可以深入探讨一下,为什么许多人会觉得macOS的体验更“顺滑”,以及Windows在这方.............
  • 回答
    macOS 和 MacBook 的确是不少人心中的“最优选”,但就像任何产品一样,它们也有自己的小瑕疵,如果事无巨细地说起来,那也挺有意思的。macOS 的“优点”与隐藏的“缺点”咱们先聊聊 macOS 本身。它最大的卖点,无疑是那个优雅、流畅的操作体验。应用之间的切换、窗口的缩放、触控板的手势,这.............
  • 回答
    macOS 内建的「黑体繁/简」系列,也就是大家常说的「华文黑体」家族,它确实是苹果在中文系统上长期以来倚重的字体之一。它在很多场景下表现得稳定且易于辨认,但要说缺点嘛,那也是相当明显的,尤其是在我们这些对文字排版有一定追求的人看来。首先,整体的粗细和字重分布不够均衡,导致视觉上的疲劳感。 华文黑体.............
  • 回答
    在 macOS 上寻找一款能与 SAI(Easy Paint Tool SAI)匹敌的绘画软件,就像在琳琅满目的画笔库里挑选最适合描绘心中色彩的那一支。SAI 以其轻巧的体积、流畅的笔触反馈和优秀的数位板支持,在很多插画师心中有着不可替代的地位。那么,在 macOS 这个平台,有哪些软件能提供类似的.............
  • 回答
    说实话,我作为一个长期浸淫在 macOS 世界里的人,最近被工作需求逼着又重新拾起了 Windows,感觉就像是突然被扔进了一个熟悉又陌生的游乐场,那些当年习惯得不能再自然的操作,现在用起来处处是坎儿。我尽量不带点技术术语,就从一个用户的角度,絮絮叨叨地跟你聊聊,那些让我这个 Mac 老司机在 Wi.............

本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度google,bing,sogou

© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有