☰

为什么这个难以理解的“查找”命令会破坏我的系统？

tag-icon • tag-icon find rm
为什么这个难以理解的“查找”命令会破坏我的系统？

我正在使用 archlinux，并且试图删除核心转储文件以节省根分区上的空间。

我愚蠢地运行了这个我在互联网上找到的东西，但并没有真正理解它：

sudo find / -xdev -name core -ls -o -path "/lib*" -prune -exec rm {} \;

据我目前了解，它将删除根目录“/”下具有完全相同名称“core”的所有内容，但“/lib”下的内容除外

这是我得到的输出

 399883 4 drwxr-xr-x 2 root root 4096 Sep 21 18:33 /usr/share/lightdm-webkit/themes/litarvan/packages/$sdk/lib/core
401640 4 drwxr-xr-x 11 root root 4096 Sep 21 18:33 /usr/share/lightdm-webkit/themes/litarvan/packages/angular2/src/core
992335 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/log/core
999740 4 drwxr-xr-x 7 root root 4096 Dec 5 14:36 /usr/include/boost/spirit/home/classic/core
999834 4 drwxr-xr-x 3 root root 4096 Dec 5 14:36 /usr/include/boost/spirit/home/x3/core
999557 4 drwxr-xr-x 3 root root 4096 Dec 5 14:36 /usr/include/boost/phoenix/core
992045 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/hana/fwd/core
992030 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/hana/core
991963 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/geometry/multi/core
991928 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/geometry/core
991626 4 drwxr-xr-x 4 root root 4096 Dec 5 14:36 /usr/include/boost/beast/experimental/core
991622 4 drwxr-xr-x 4 root root 4096 Dec 5 14:36 /usr/include/boost/beast/core
991735 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/contract/detail/inlined/core
991731 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/contract/core
1000174 4 drwxr-xr-x 3 root root 4096 Dec 5 14:36 /usr/include/boost/xpressive/detail/core
991744 4 drwxr-xr-x 2 root root 4096 Dec 5 14:36 /usr/include/boost/core
1062959 4 drwxr-xr-x 3 root root 4096 Dec 6 01:31 /usr/lib/python3.7/site-packages/ranger/core
1088768 4 drwxr-xr-x 3 root root 4096 Oct 22 21:00 /usr/lib/python3.7/site-packages/core
450582 4 drwxr-xr-x 6 root root 4096 Dec 6 01:07 /usr/lib/ruby/gems/2.5.0/gems/rspec-core-3.8.0/lib/rspec/core
1008621 4 drwxr-xr-x 4 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/sound/core
1008442 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/usb/core
1007844 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/infiniband/core
1008479 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/video/fbdev/core
1007786 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/gpu/drm/tinydrm/core
1008033 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/mmc/core
1008005 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/memstick/core
1008133 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/drivers/net/ethernet/mellanox/mlx5/core
1008569 4 drwxr-xr-x 2 root root 4096 Dec 20 14:03 /usr/lib/modules/4.19.10-arch1-1-ARCH/kernel/net/core
415080 4 drwxr-xr-x 4 root root 4096 Sep 9 09:36 /usr/lib/python2.7/site-packages/wx-3.0-gtk3/wx/lib/pubsub/core
1074158 4 drwxr-xr-x 2 root root 4096 Sep 7 03:10 /usr/lib/python2.7/site-packages/radialnet/core

因此，所有匹配项都是目录，并且因为我使用rm不带-r选项，所以它不应该删除目录，这意味着它不应该删除任何内容。

然而，在我运行该命令之后，系统中的大多数东西都坏了，例如 zsh、i3。当我重新启动电脑时，出现了内核恐慌、坏的 rip 值或其他问题。

我可以重新安装，因为我有单独的根分区和主分区。但我很好奇为什么它会破坏系统。

答案1

一些相关片段find规格：

-xdev
主设备应始终评估为真；它应导致 find 不会继续下降到具有不同设备 ID 的目录 […]。如果-xdev指定了任何主设备，则它应适用于整个表达式，即使主-xdev设备通常不会被评估。

-prune
主路径应始终评估为真；如果路径是目录，则应导致 find 不下降当前路径名。[…]

[…]

可以使用以下运算符来组合原色（按优先级从高到低的顺序）：

[…]

expression [-a] expression
主元的结合；AND 运算符由两个主元的并置暗示或由可选运算符明确表示-a。如果第一个表达式为假，则不应评估第二个表达式。

expression -o expression
主元交替；或运算符。如果第一个表达式为真，则不应计算第二个表达式。

现在您的命令（只是为了让它在眼前）：

find / -xdev -name core -ls -o -path "/lib*" -prune -exec rm {} \;

一些结论和事实：

  1. -xdev适用于一切，甚至适用于之后的部分-o。
  2. 因为并列（或-a）在之前-o，所以你的命令就像( expression1 ) -o ( expression2 )（比较这个答案）。
  3. 您看到的所有输出均来自-ls。
  4. 无论何时-ls工作，第一个表达式都是真，因此第二个表达式不会被评估（这意味着您看到的匹配项不会被删除）。
  5. -path "/lib*"匹配这些对象：
    • 名称lib*直接匹配的目录/，
    • lib*名称直接匹配的非目录/，
    • 来自第一个项目符号的目录内的所有对象（在您的情况下不是，因为-prune）。

rm对满足以下所有条件的任何对象都会调用此方法：

  1. 它与 属于同一文件系统/（因为-xdev）。
  2. 它没有命名core（因为它的-o工作原理）。
  3. 它直接在/并且它的名称匹配lib*。

我在我的 Kubuntu 中运行这个来打印这样的对象：

find / -xdev -name core -o -path "/lib*" -prune -print

结果是

/lib
/lib64
/lib32

这些都是目录，单独rm（没有-r）无法删除它。我确信在我的例子中，你的原始命令不会破坏系统。然而如果任何匹配的对象都不是目录，rm很可能会将其删除。

FHS——文件系统层次标准说：

/lib32可能/lib64是库目录，以及/lib其中一个的符号链接。

我猜测你/lib可能有一个符号链接，rm删除它没有问题。此位置用于存放基本共享库和内核模块（请参阅 FHS 或这个答案），难怪你破坏了你的系统。我不能确定没有其他lib*非目录也被删除了；但如果我对/lib那时的判断是正确的或许重新创建符号链接就是修复系统所需的全部内容。

在我的另一个答案第一个建议是

写 100 次“我不会以 root 身份运行我不理解的命令”。:)

但看起来你已经吸取了教训。

相关内容