Why this hard-to-understand 'find' command broke my system?

Question

I am using archlinux and I was trying to delete core dumps file to save space on the root partition.

I stupidly ran this which I found in internet without really understanding it:

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

from what I understand so far. It will delete everything under root '/' that has the exact name 'core' except anything under '/lib'

and this is the output I got

 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

So, all of the matches are directory, and because I use rm without the -r option, it should not delete directories, which means it should delete nothing.

However, after I ran the command, most of the things in my system broke, e.g., zsh, i3. and when I reboot my PC, I got a kernel panic, bad rip value or something.

I could reinstall again since I have separate root and home partition. But I'm very curious why it broke the system.

Answer 1

Some relevant fragments of find specification:

-xdev
The primary shall always evaluate as true; it shall cause find not to continue descending past directories that have a different device ID […]. If any -xdev primary is specified, it shall apply to the entire expression even if the -xdev primary would not normally be evaluated.

-prune
The primary shall always evaluate as true; it shall cause find not to descend the current pathname if it is a directory. […]

[…]

The primaries can be combined using the following operators (in order of decreasing precedence):

[…]

expression [-a] expression
Conjunction of primaries; the AND operator is implied by the juxtaposition of two primaries or made explicit by the optional -a operator. The second expression shall not be evaluated if the first expression is false.

expression -o expression
Alternation of primaries; the OR operator. The second expression shall not be evaluated if the first expression is true.

Now your command (just to have it in sight):

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

Some conclusions and facts:

1. -xdev applies to everything, even to the part after -o.
2. Because juxtaposition (or -a) precedes -o, your command is like ( expression1 ) -o ( expression2 ) (compare this answer).
3. All the output you saw came from -ls.
4. Whenever -ls worked, the first expression was true, so the second one was not evaluated (which means matches you saw were not removed).
5. -path "/lib*" matches these objects:
   • directories with names matching lib* directly in /,
   • non-directories with names matching lib* directly in /,
   • all objects inside directories from the first bullet point (not in your case, because of -prune).

So rm was invoked for any object that fulfills all of the following conditions:

1. It belongs to the same filesystem as / (because of -xdev).
2. It's not named core (because of how -o works).
3. It's directly in / and its name matches lib*.

I run this in my Kubuntu to print such objects:

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

and the result was

/lib
/lib64
/lib32

Each of these is a directory, sole rm (without -r) cannot remove it. I'm pretty sure in my case your original command wouldn't break the system. However if any matching object was not a directory, rm would most likely remove it.

FHS - Filesystem Hierarchy Standard says:

/lib32 and /lib64 might be the library directories, and /lib a symlink to one of them.

I guess your /lib may have been a symlink and rm had no problem removing it. This location is for essential shared libraries and kernel modules (see FHS or this answer), no wonder you broke your system. I can't be sure there was no other lib* non-directory which was also removed; but if I'm right about /lib then maybe recreating the symlink is all you need to fix the system.

In another answer of mine the first advice is

Write 100 times "I won't run commands I don't understand as root". :)

but it looks like you have already learnt your lesson.