/etc/shells 说它已zsh安装在 中/bin/zsh，但也安装在/usr/bin/zsh.
brgr@envy17:~$ cat /etc/shells
# /etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
/usr/bin/tmux
/usr/bin/screen
/bin/zsh <--
/usr/bin/zsh <--
现在互联网建议我使用 中的一个/usr/bin/。
我的问题是：为什么？这两者之间有什么区别？为什么 bash 仅安装在一个路径 ( /bin/bash) 上？
答案1
的内容/etc/shells或多或少是静态的，与系统上安装的特定 shell 的存在无关。
事实上，您的/etc/shells文件中有两个条目，仅意味着如果用户在 中将其中一个/bin/zsh或/usr/bin/zsh指定为其 shell /etc/passwd，那么它们都会被咨询的守护进程/etc/shells（例如大多数 FTP 守护进程）视为“有效”。
要查看路径 ($PATH) 中第一个可用的 zsh，您可以使用 which 命令，如下所示：
which zsh
或者 whereis，它显示更多信息（命令的二进制文件、源文件和手册页文件）：
whereis zsh
答案2
一个可能是另一个的符号链接（或硬链接）......但它们是相同的文件。
答案3
当/bin/zsh存在时，多余的的存在/usr/bin/zsh主要目的是可移植性从某种意义上说，您不需要编辑每个脚本”舍邦行，当使用 时zsh，可能会解决/usr/bin/zsh.
zsh不被视为标准软件，但越来越多的人在使用它，甚至包括核心系统管理员。这就是为什么更多的发行版也倾向于将其放入其中/bin/zsh。
言归正传：这不是一个zsh问题，而是一个问题特征这应该保证将 Linux（或历史上的 Unix）系统引导到定义的状态。
/bin被定义为驻留在根文件系统中，而/usr/bin不是。
对于后者（除其他外），选项包括将其放在另一个磁盘（分区）甚至另一台机器上，并通过 NFS 或其他网络方式安装。
因此，当在没有网络支持的情况下启动系统时，或者网络意外中断时，或者磁盘崩溃或文件系统损坏时，或者只是启动到单用户模式而不安装任何内容时，/bin仍然可以访问其中的文件。
这同样适用于/lib和/usr/lib：事实上，超出的任何内容/usr都被认为对于基本系统来说并不重要（X11 通常也可以在/usr分支中的某个地方找到。这也是 root 的 $HOME 不是的原因/home/root，因为/home也被认为不是驻留在根文件系统中。
如果系统盘坏了怎么办？或者根文件系统已损坏？好吧，那么很可能你甚至无法加载内核......
上述大部分内容对于当今的系统来说并不是太重要。 NFS 安装的/usr/*文件系统是不必要的，因为磁盘空间便宜且可用。
在许多安装中，甚至操作系统映像都安装到单独的/boot文件系统中，因此加载内核并不能保证能够挂载根文件系统，但目前我们拥有initrd一个可工作的初始根文件系统内核启动（事实上，zsh在大多数情况下会丢失）。
拥有一个包含/usr分支的大根文件系统也是常见的做法，这在克隆安装时具有一些优势。
因此，导致区分/bin和/usr/bin（等等）的传统考虑有点过时了，但仍在最近的系统中实现。
（这更多的是旁白，但这些都是事实）
答案4
出于兼容性原因。一些脚本使用 /usr/bin，其他脚本使用 /bin。一些发行版希望将所有内容移至 /usr/bin，因为 /sbin 和 /bin 已经没有多大意义了。例外之一是 bash，因为#!/bin/bash在过去的几十年中已在无数脚本中使用，因此提供 /bin/bash 来实现兼容性并带有符号链接，目前是一个很好的解决方案。