Pourquoi cette commande difficile à comprendre "trouver" a cassé mon système?

J'utilise archlinux et j'essayais de supprimer le fichier core dumps pour économiser de l'espace sur la partition racine.

J'ai bêtement couru ce que j'ai trouvé sur Internet sans vraiment le comprendre:

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

de ce que je comprends jusqu'à présent. Il supprimera tout ce qui se trouve sous la racine '/' et porte exactement le nom 'core', à l'exception de '/ lib'

et ceci est la sortie que j'ai

 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

Donc, toutes les correspondances sont des répertoires, et parce que j'utilise rm sans le -r option, il ne faut pas supprimer les répertoires, ce qui signifie qu'il ne faut rien supprimer.

Cependant, après l'exécution de la commande, la plupart des éléments de mon système se sont cassés, par exemple zsh, i3. et quand je redémarre mon PC, j'ai eu une panique du noyau, une mauvaise valeur d'extraction ou quelque chose.

Je pourrais réinstaller à nouveau puisque j'ai la partition principale et la partition principale. Mais je suis très curieux de savoir pourquoi cela a brisé le système.

Quelques fragments pertinents de find spécification :

-xdev
Le primaire doit toujours évaluer comme vrai; cause, find ne continuera plus à descendre dans les répertoires précédents ayant un identifiant d'appareil différent […]. Si seulement -xdev primaire est spécifié, il doit s'appliquer à l'expression entière même si le -xdev primaire ne serait normalement pas évalué.

-prune
Le primaire doit toujours évaluer comme vrai; il fera en sorte que find ne descende pas le chemin actuel s'il s'agit d'un répertoire. […]

[…]

Les primaires peuvent être combinées à l'aide des opérateurs suivants (par ordre de priorité décroissant):

[…]

expression [-a] expression
Conjonction de primaires; l'opérateur AND est impliqué par la juxtaposition de deux primaires ou rendu explicite par l'option -a opérateur. La deuxième expression ne doit pas être évaluée si la première expression est fausse.

expression -o expression
Alternance de primaires; l'opérateur OR. La deuxième expression ne doit pas être évaluée si la première expression est vraie.

Maintenant votre commande (juste pour l'avoir en vue):

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

Quelques conclusions et faits:

1. -xdev s'applique à tout, même à la partie après -o.
2. Parce que la juxtaposition (ou -a ) précède -o, votre commande est comme ( expression1 ) -o ( expression2 ) (comparer cette réponse ).
3. Toutes les sorties que vous avez vues venaient de -ls.
4. N'importe quand -ls a fonctionné, la première expression était vraie, donc la seconde n'a pas été évaluée (ce qui signifie que les correspondances que vous avez vues n'ont pas été supprimées)
5. -path "/lib*" correspond à ces objets:
   • répertoires avec des noms correspondants lib* directement dans /,
   • non-répertoires avec des noms correspondants lib* directement dans /,
   • tous les objets dans les répertoires à partir du premier point (pas dans votre cas, à cause de -prune ).

Alors rm a été invoqué pour tout objet remplissant toutes les conditions suivantes:

1. Il appartient au même système de fichiers que / (en raison de -xdev ).
2. Ce n'est pas nommé core (à cause de comment -o travaux).
3. C'est directement dans / et son nom correspond lib*.

Je lance ceci dans mon Kubuntu pour imprimer de tels objets:

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

et le résultat était

/lib
/lib64
/lib32

Chacun de ceux-ci est un répertoire, unique rm (sans pour autant -r ) ne peut pas l'enlever. Je suis presque sûr que dans mon cas, votre commande originale ne briserait pas le système. toutefois si tout objet correspondant n'était pas un répertoire, rm serait probablement le supprimer.

FHS - Norme de hiérarchie des systèmes de fichiers dit:

/lib32 et /lib64 pourrait être les répertoires de la bibliothèque, et /lib un lien symbolique vers l'un d'entre eux.

je deviner votre /lib peut avoir été un lien symbolique et rm eu aucun problème pour l'enlever. Cet emplacement concerne les bibliothèques partagées essentielles et les modules du noyau (voir FHS ou cette réponse ), pas étonnant que vous avez cassé votre système. Je ne peux pas être sûr qu'il n'y avait pas d'autre lib* non-répertoire qui a également été supprimé; mais si j'ai raison à propos de /lib puis peut être recréer le lien symbolique est tout ce dont vous avez besoin pour réparer le système.

Dans une autre de mes réponses le premier conseil est

Ecrivez 100 fois "Je ne lancerai pas de commandes que je ne comprend pas en tant que root". :)

mais il semble que vous ayez déjà appris votre leçon.