CentOS 7 symlinking ALL the bins

I got quite the surprise on CentOS 7 today. While attempting to move a file (let's call it file x), I got the strangest error.

$ mv /sbin/x /usr/sbin/x
==> mv: cannot move ‘x/’ to a subdirectory of itself.

Wait, what? Did I type that right?

Not to get all Malcolm Gladwell on you (again), but turns out, CentOS 7 introdues this file system structure.

$ ls -l /
==> bin -> usr/bin
==> lib -> usr/lib
==> lib64 -> usr/lib64
==> sbin -> usr/bin

That's right, /{s}bin and /lib{64} are symlinked to their respective /usr.


As a BSD user first (here we go), it took me this long to feel okay having Linux mix userland and system utitilies. Now, we're further collapsing these directories into one place. I'd be interested to hear their justification; on the surface it seems short sighted.

By comparison, BSD documents clear separations between these. FreeBSD's hier(7) manpage defines them as:

/bin: user utilities fundamental to both single-user and multi-user environments

/usr/bin: common utilities, programming tools, and applications

/usr/local: local executables, libraries, etc. Also used as the default destination for the FreeBSD ports framework.

Granted, the distinction between system and package manager maintained assets is moot on Linux distros, as they're all updated from apt-get, yum and so on. Whether this is a good idea or not is beyond the scope of this post.

But still, it's interesting these distinctions are no longer deemed relevent to CentOS (or perhaps Prominent North American Enterprise Linux vendor Red Hat). Mixing bash with your gcc? Sure, you're tangling all your stuff with systemd anyway.


This is one of about 5000 posts on Rubénerd. View the home page for the latest, or related posts also tagged with:

If you liked this post, feel free to buy me a coffee, leave me a comment on Twitter, or email me at weblog2017@rubenschade.com. Thanks :).