让我们弄清楚所有bin和sbin文件夹（来自文件系统层次结构标准）：

• /bin 用于系统级二进制文件
• /sbin 用于其他系统级二进制文件，主要用于引导加载程序和系统管理员
• /usr/bin 适用于非必需的二进制文件
• /usr/sbin-这是混乱的开始-不是系统管理员必备的工具吗？这是什么意思？为了实验？
• /usr/local/bin -关于此文件夹的任何消息
• /usr/local/sbin-本地安装的系统管理程序。再次？怎么/usr/sbin样

所以问题是：为什么目录这么多/usr/sbin，/usr/local/sbin和的含义是/usr/local/bin什么？

许多程序是通过存档分发的，我们必须从源代码构建它们。通常他们有makefile，所以这很容易。此过程涉及在usr / local / lib，usr / local / bin ... usr / local /随便什么目录中创建文件，而无需为给定程序创建特定文件夹。

为什么会这样呢？

我认为这是不对的，因为如果我们需要删除程序，那么如果程序的创建者不注意它，则必须手动删除其所有文件。

1.目录结构

这应该在文件系统层次结构标准 （2.3 PDF）中涵盖

/ bin /需要在单用户模式下可用的基本命令二进制文件；
            适用于所有用户，例如cat，ls，cp

/ sbin /基本系统二进制文件，例如init，ip，mount。

/ usr / bin /非必需的命令二进制文件（在单用户模式下不需要）； 
            对于所有用户

/ usr / sbin /非必需的系统二进制文件，例如，各种网络服务的守护程序。

/ usr / local /用于此主机的本地数据的第三层。 
            通常具有其他子目录，例如bin /，lib /，share /

2.安装

我尽可能使用软件包管理器（例如yum或apt-get）。这对于大量应用程序是可能的，在某些情况下，您可能必须添加存储库。我的第二个选择是RPM等较低级别的程序包，而从源代码进行编译将是我的最后选择（但有些人更喜欢这样做）

一些软件包管理器可以从RPM安装（例如yum install oddity.rpm）

如果您是从源代码编译的，那么创建自己的程序包可能不是一个巨大的步骤，以便系统安装程序知道您所做的事情。

然后您的问题减少到例如 yum remove packagename

另一种方法是保留有关进行的所有sysadmin活动的良好文档（无论如何，我始终将日记保存在文本文件中）

所有* / sbin目录中的内容通常仅对系统管理员有用。如果您是普通用户，则可以将其排除在PATH外。

如果您在单个磁盘上只有一台Unix机器，那么不同的目录没有多大意义，但是如果您有一个大系统和不同的分区，那么这些目录就更有意义。请记住，许多习惯都是在80和90年代制定的，当时系统有所不同。

/sbin往往是非常小的。这些是真正需要胶管的工具。您可以将其放在带有/ root和/ lib的最小根分区上。/ sbin中的内容以前都是静态链接的，因为如果对/ usr分区进行了缓冲处理，那么任何动态链接的应用程序都将无用。fsck在这里并静态链接。如果您对/ usr有依赖性，显然您不能fsck / usr /。当然，如果根分区用软管连接了，那您就很费劲。这就是为什么这是一个很小的分区的原因-通过在此处使用很少的块来降低坏磁盘块的几率。

/usr/sbin二进制文件是常规的sysadmin工具，您至少可以进入单用户模式并挂载所有卷。它们被允许动态链接。

当您记得备份在时间和磁带上都非常昂贵时，/ sbin（/分区上的/ sbin）和/ usr的单独分区也更有意义。如果它们在单独的分区上，则可以对它们进行不同的调度。

/usr/local可以是网络文件系统。因此，可以在许多计算机上共享的本地编写的sysadmin工具有时会放在/ usr / local / sbin中。显然，没有网络修复工具可以去那里。

同样，在联网环境中的大型计算机上，在具有多个卷的受管计算机上，很多事情都有意义，而在单个根分区上的一台Linux计算机上，情况则更是如此。

您真的应该在Superuser上将第二个问题作为一个单独的问题。与第一个无关。

是的，到处都有文件很烂。这就是为什么有很多包装解决方案的原因。RedHat创建了RPM，该RPM随处可见。Solaris具有其软件包格式。HP / UX拥有它们，并且有apt和许多其他软件包格式。将内容适当地放在正确的位置（/ usr / bin，/ usr / lib），但允许轻松添加和删除。

对于源代码，曾经有一些工具可以让您在/ usr / local的子目录中进行配置和安装，并且可以为您处理到/ usr / local / bin的符号链接。由于打包工具的广泛使用，因此它的必要性降低了，我忘记了它们的名称。

有些人喜欢安装在/ opt / 软件包名称中，并将所有内容放在一起。好处是：所有内容都在一个目录中，而卸载则在rm -rf /opt/packagename。这样做的缺点是必须将/ opt / packagename / bin添加到每个人的PATH中，而且人们通常不会将/ opt放在单独的分区上，而是您填充了根分区。

我对目录含义的理解（来自Debian GNU Linux的经验）是：

第一个区别：s用于超级用户

s一个前bin目录表明，它包含了通常只有管理员有用的工具。请注意，例如ifconfig也属于此类别，并且我希望以ifconfig普通用户身份进行调用（以检查我是否有IP地址/网络连接），这使得这种区别似乎并不那么困难。

第二个区别：local用于“本地数据”

实际上，这里最重要的区别是OS软件包管理器（如APT）将软件包安装到正常/usr结构，并且/usr/local不受影响。这允许将本地编译的程序包或系统管理员提供的公司内部脚本放在/usr/local不会干扰正确打包文件的位置。

是否/usr/local应该从常规/usr结构中覆盖现有文件，尚有待商,，请参阅在自己的PATH中将/ usr / local / bin放在/ usr / bin之前是否危险？有关此的一些详细信息。

第三个区别：顶层/bin和/sbin目录。

在Debian上，实际上有一个所谓的UsrMerge。曾经/bin和/sbin以前在引导过程中/usr存在差异（以前认为是在网络设备或不同的分区，RAID等上），但是如今很少有Linux系统可以很好地引导，/usr这就是为什么我会考虑在顶级操作系统之间进行区别的原因。级别和/usr目录在很大程度上对Linux具有历史意义。

最后：“分散”文件的优缺点。

对此确实没有“一个真实”的答案。Linux分散文件系统的优点如下：

• 所有二进制文件都位于几个目录中。这意味着您可以从外壳程序调用每个程序。比较Windows，总是需要编辑%PATH%环境变量以添加任何感兴趣的程序。我在Windows上看到了很长的路径环境。

• 所有图书馆都位于中央。这意味着当被多个应用程序使用时，它们不需要安装两次。

• 由于Linux是按设计的，无论如何大多数程序文件都是由包管理器跟踪的，因此无需从用户角度对文件进行概述。

• 由于FHS标准化，文档也位于中心地使系统能够喜欢man，info并支持自述文件，以正常工作。

• 依赖于安装在固定位置的程序会更容易。每个人#!/bin/sh -e在脚本开始时都会写东西或类似的东西，它只是有效。考虑一个将shell转到另一个目录的系统：一个人怎么知道它将取什么名字？如果有兴趣，请检查在Windows上安装Perl或LaTeX的各种方法，以了解这会变得多么复杂...

到目前为止，我发现的缺点是：

• 通常，从“适用于Windows的便携式应用程序”的意义上说，“便携式”运行应用程序比较困难。在Linux上，将程序复制到另一台计算机不是那么容易...一个人需要拥有该软件包（需要root权限）或进行处理，LD_LIBRARY_PATH以将应用程序指向所需库的不同搜索路径。

• 需要明确支持安装同一程序的多个版本，而在具有“每个程序一个目录”的系统上，这通常不是问题。

• 在没有包管理器的情况下管理文件容易出错（如上所述）。

要回答第二个问题：
通常，程序是通过所谓的包管理器分发的。程序包管理器通常获取二进制程序包（为某个平台编译的软件），然后将其扔到目录周围（有些人会下载源代码，然后在计算机上进行编译并安装）。因此，程序包管理器知道属于某些“程序”（程序包）的文件在哪里，并且当您要删除程序包时，程序包管理器会负责清理所有内容。
即使您自己使用编译源代码

make

并安装

make install

你通常可以做

make uninstall

从文件系统中删除文件。