运行 Ubuntu 17.04，我正在从非存储库发行版安装软件，我应该将软件 bin 文件夹内容移动到 /usr/bin （这已经是不确定的建议）
这是那些日子之一，所以我做了什么：
mv /bin/* /usr/bin
所以我搞砸了，我不小心将 bin 中的所有文件移动到了 /usr/bin 并且 /bin 是空的。由于我认为 /bin 是系统关键，为了快速补救，我将 /usr/bin 内容复制到 /bin。
现在我的 /bin 和 /usr/bin 内容相同，并且都包含最初在 /bin 和 /usr/bin 中分开的文件。
我没有安装 Timeshift，所以恢复备份不是一个选项，但目前计算机上没有任何重要的东西，所以我只能承认搞砸了重新安装整个 linux 分区。
Sté*_*las 36
在 Linux 上（以及在大多数其他系统上，尽管 POSIX 不会给你这种保证，除非移动是跨文件系统），这会更新它们的 ctime，因此假设/usr/bin在过去 24 小时内没有其他任何人被触及，您应该能够将它们移回：
find /usr/bin/. ! -name . -prune -ctime -1 -exec sh -c '
echo mv -i "$@" /bin' sh {} +
echo如果看起来正确，请删除。请注意，您将无法收回，在存在同名的文件/bin和/usr/bin（与原有的在/usr/bin将已丢失）
一个潜在的警告：如果某些文件在/bin和/usr/bin中都进行了硬链接，则 中的所有硬链接/usr/bin都将移动到/bin。
现在，你可能会认为，既然/bin和/usr/bin在默认$PATH，并且/bin可在/boot至少前/usr安装，它不应该不管是否可执行文件是/bin不是/usr/bin。
但这会忽略许多命令对可执行文件的路径进行硬编码并期望它们在某些特定情况下。一个常见的例子是她的刘海。所有具有以下功能的脚本：
#! /usr/bin/env bash
执行后将无法工作mv /usr/bin/env /bin/env。在这方面，在两个位置都使用命令更安全，因为它不会破坏这些脚本。
Bas*_*tch 19
我的 Ubuntu 现在处于损坏状态吗？
是的，你的 Ubuntu 坏了
你搞砸了一些对包管理很重要的事情。
因此，在实践中，备份您的重要数据（至少/etc和/home），也许还有已安装软件包的列表，例如 的输出dpkg -l，然后重新安装 Ubuntu。
（非新手可以尝试管理 - 就像在其他答案中一样 - 但那样他就不会犯这么大和基本的错误）
我只能承认搞砸了重新安装整个 linux 分区。
这可能会占用您更少的时间。在其他答案的帮助下保持您当前的系统使其处于非常混乱的状态（这会给您带来未来的麻烦）。
由于您正在重新格式化磁盘，请考虑放置/home一个单独的分区（这样将来此类错误不会丢失您的数据）。这样做在纸张上打印输出之前df -h和df -hi和fdisk -l（他们提供有关使用磁盘空间-既以及可供...信息）。明智的做法是拥有足够大的系统分区（根文件系统）；如果您负担得起，100 GB 就足够了。
我应该将软件 bin 文件夹内容移动到 /usr/bin
（术语：Unix 有目录，而不是“文件夹”）。
这（移动到/usr/bin/）是非常错误的。无论是提高你的$ PATH（最好），或至多可加符号链接中/usr/bin/，最好移动（或添加符号链接）可执行文件/usr/local/bin/。
明智的做法是永远不会改变/usr/bin/，/bin，/sbin，/usr/sbin/ 的软件包管理工具外（例如dpkg，apt-get，aptitude等...）。阅读FHS。
Ste*_*itt 17
您的安装应该基本没问题；不应该有在同一个名称不同的文件/usr和/usr/bin（其中回答你的2.1），所以有两个中的所有文件/bin，并/usr/bin不会破坏任何东西（直到你升级包）。如果您用符号链接覆盖了二进制文件，那么您现在可能遇到的唯一问题是符号链接损坏。要解决此问题，请查找损坏的符号链接：
find -L /bin /usr/bin -type l -ls
并重新安装与列出的文件相对应的所有软件包（例如，如果/usr/bin/zsh显示为损坏，dpkg -S /bin/zsh /usr/bin/zsh则会告诉您该文件来自哪个软件包；使用 重新安装它apt --reinstall install zsh）。
您可以按 ctime 显示和排序以查看最近更改的文件（包括您移动的文件）：
ls -ltc /bin
撤消您所做操作的最佳方法是使用cruft包并删除它在其中找到/bin或/usr/bin不来自包的文件：
sudo apt install cruft
sudo cruft -d "/ /usr"
除非文件是文件的符号链接/etc/alternatives（在这种情况下，您应该不理会它们）。
详细说明为什么您的系统或多或少“损坏”的原因可能具有教育意义。
/bin在它们应该在的时候发现二进制文件，它有可能变得非常混乱/usr/bin，反之亦然。$PATH）。/bin和之间存在区别的原因是/usr/bin前者可能位于在引导的较早阶段安装的分区上。在这种情况下（即，在引导系统时），不仅/bin/xxx二进制文件可能会被完整路径引用，而且该目录/usr/bin在那时系统上可能不可用。（如果您使用df /bin和df /usr/bin，您可能会看到列出的相同文件系统或不同的文件系统；现在可能大多数默认安装都将两个目录保留在同一分区中）。因此，您可以看到，如果您在和 中具有相同的二进制文件，则不会发生问题 2 和 3，并且 1 的损坏可能很小。例如，Re 1，如果您尝试删除软件包，则可能无法正确卸载它们；如果升级尝试升级“正确”位置的副本，但忽略“错误”位置的副本，则升级可能会出现乱码。因此，如果上述补救措施看起来过于激烈或过于复杂，您可以让系统保持这种状态。/bin/usr/bin
但如果这是一个重要的系统，我真的不会指望它。
一般规则（再次呼应@basile-starynkevitch）永远不要与/usr/bin,/bin和朋友玩弄- 他们“属于”发行版 - 并且建议将这样做作为其正常安装的一部分的包是......不是一个好包。
编辑：有关第3点，有一个在systemd / Fedora和朋友的背景下讨论的，为什么是有意义的移动的所有内容/bin到/usr/bin，而符号的第一到第二。这不是建议您自己这样做——该页面是写给分发的人的——但它包含了为什么这种区别存在的一些历史（以及为什么它现在只是尘土飞扬的传统）。