场景
在编译wine前，执行.configure检查依赖项是否都满足条件，发现bison的版本较低。
检查发现存在一个/usr/bin/bison，但是从未安装过这一命令，所以考虑到是XTools中携带的，检查后发现确实如此
然后就又一次引发了我对于XTool的疑问，/usr/bin/下和XTools中包含的相同可执行程序，不是以软连接形式存在的，那么我第一步想到的就是硬链接，难道意味着XTools在安装时把对应程序的硬链接写入到/usr/bin/中吗？有没有官方文档说明这一点？
事实上，并没有官方文档提到这一点。不过我从另一个角度发现一些似乎是矛盾的东西。对于XTool的卸载，官方给出的方法是可以直接删除XTools所在的文件夹，我随之产生一个疑惑：删除了XTools的文件夹，下面的程序确实是没有了，那/usr/bin/下的不是还存在吗，为何就不能再使用了，这样确定能卸载吗？
由于在安装XTools之前并没有检查过/usr/bin/目录，所以不确定最初状态下系统的状态了，但是卸载XTools来检查这一点的成本有点高，不过找到了为什么 macOS 在 /usr/bin/ 下会有 python3?这个问题，其中有人已经使用虚拟机尝试过这一点了，直接删除XTools所在目录确实就不再能执行相关的程序了，只删除这一个目录，又没有动/usr/bin/目录，所以那些同名的可执行文件都还在，既然不是软连接，但是为什么就不能执行了，因此很自然就开始考虑/usr/bin/下那些可执行文件到底是什么，如果是按照最初的猜想是硬链接的话，删除原文件，不会影响硬链接的可执行性，现在无法执行，也就说明了它们并非硬链接，那到底是什么？
从为什么 macOS 在 /usr/bin/ 下会有 python3?的一位答主的回答中了解到一个新的命令otool，类似Linux下的ldd，可以查看可执行程序用到的库，检查XTools下和/usr/bin/下的同名可执行文件就可以发现端倪，它们并不相同。简单来说，/usr/bin/下的类似git等工具并不是一个完整的git，大致可以看为是一个代理程序。通过深入浅出Xcode Command Lines Tool(1) - 初探序列文章，又了解到XTools实际有一个版本控制机制。把这两点结合起来看，我们就可以大致理解为，mac正是借助/usr/bin/下的这些所谓的代理程序，再结合xcode-select --switch这类工具，实现了对于XTools的版本控制，在一台机器上可以安装多个版本的XTool。如果安装XTools时只是简单在/usr/bin/下创建软连接或者硬链接，显然都是无法完美地实现这一点。/usr/bin/下的程序充当了抽象层，里面的可执行程序都是逻辑上的可执行程序，并非实体，具体映射到哪个版本的实际可执行程序，则可以由其他工具进行指定的
核心矛盾出现在，XTools的卸载仅仅是删除了XTools的目录，即使/usr/bin/存在同名的可执行程序，但是却无法执行
如果/usr/bin/下的程序是软连接或硬链接，都不应该是这样的表现
回过头来看，应该在机器刚刚激活后，'/usr/bin/`下就已经存在一些代理程序了，当找不到XTools时，就会提示去安装XTools，如果找得到就去执行。
本质上还是一种抽象机制，便于实现版本控制（很巧妙的实现）
由此也了解到了一种单机多版本应用控制的新的实现思路，通过建立抽象层，借助一些指定版本的工具，实现版本控制
标签：bin,版本控制,Xcode,链接,usr,思考,XTools,Tools,可执行程序 From： https://blog.51cto.com/u_14882565/11901084