Right, let’s talk about the three bins in the room: /bin, /sbin, and /usr/bin. You’ve seen them. You’ve probably used them without a second thought. But why are there three places for what is essentially the same thing: executable programs? The answer is a delightful mix of historical baggage, practical necessity, and a few decisions that make you wonder if the designers were running on a serious caffeine deficit.

It all boils down to one question: “What do you absolutely need to boot and repair a system when your /usr partition is sitting on a network drive that hasn’t mounted yet, or is corrupted beyond recognition?” This isn’t a theoretical question. I’ve been there, staring at a initramfs prompt, thanking my lucky stars that ls, mount, and fsck were still available. That’s the core of the split.

The Great Schism: /bin vs. /sbin

The original Unix distinction was simple: /bin was for everyone (ls, cp, cat), while /sbin was for the system administrator (fdisk, fsck, ifconfig). The ’s’ literally stands for “system” or “superuser,” depending on who you ask. The key idea was that /sbin tools could affect the entire system and often required root privileges to do anything useful.

On a modern Linux system, this distinction is still technically true but practically blurry. Let’s see what’s actually in there. Open a terminal and have a look:

ls /bin | head -5
# bash
# cat
# chgrp
# chmod
# chown

ls /sbin | head -5
# agetty
# blkid
# blockdev
# cfdisk
# dmesg

See? /bin has your bread-and-butter tools. /sbin has the scary stuff you break a system with. But here’s the modern twist: for convenience, most distributions symlink the essential /sbin tools into /usr/sbin and then put that directory in the default PATH for the root user. It’s a mess, but it’s our mess.

The /usr/bin Heist

Ah, /usr. Originally, it meant “User System Resources,” a place for things not strictly necessary for booting. So, /bin and /sbin had the bare-minimum, life-support binaries. Everything else—your compilers, your text editors, your games—went to /usr/bin.

Then, we all got bigger hard drives and stopped needing to split the OS across multiple partitions. The FHS guys had a moment of clarity and said, “This is ridiculous. Let’s just put everything in /usr and symlink the essential stuff back to /bin and /sbin for backwards compatibility.” This is the usrmerge you might have heard about. It’s a sane solution to a problem we created for ourselves decades ago.

You can check if your system has done this with a simple ls -l:

ls -ld /bin /sbin
# lrwxrwxrwx 1 root root 7 Apr 18  2023 /bin -> usr/bin
# lrwxrwxrwx 1 root root 7 Apr 18  2023 /sbin -> usr/sbin

If you see that, congratulations, you’re on a sensible, modern system. The binaries physically live in /usr/bin and /usr/sbin, but the old paths are preserved so every ancient script in the universe doesn’t break.

Best Practices and Pitfalls

This history lesson isn’t just trivia; it has real-world implications.

  1. Your PATH Variable: This is the big one. As a regular user, your PATH likely includes /usr/local/bin:/usr/bin:/bin. Notice /sbin is missing. That’s on purpose. You don’t need, and shouldn’t have, immediate access to fdisk. When you need to run an sbin tool, you’ll either become root (sudo -i) or call it directly with sudo /sbin/blkid. Don’t add /sbin to your user’s PATH; it’s a security anti-pattern.

  2. Scripting and Hardcoded Paths: This is the pitfall. Never, ever hardcode #!/bin/bash or /bin/cp in your scripts. Why? What if a system uses bash from /usr/bin? Or is a BSD system where nothing is where you expect? Use the env shebang for portability. Bad:

    #!/bin/bash
cp /bin/myfile /tmp

    Good:

    #!/usr/bin/env bash
cp "$(command -v cp)" myfile /tmp

    Using env finds bash in your PATH, and command -v finds the path to cp reliably.

  3. Compiling from Source: When you make install something, it usually goes to /usr/local/bin by default. This is deliberate. /usr/bin is for the package manager’s stuff. /usr/local/bin is for you. This keeps your custom-compiled nginx from getting overwritten the next time you run apt upgrade. It’s a clean separation of church and state.

So, there you have it. The filesystem hierarchy isn’t just arbitrary; it’s a fossil record of computing history. It’s a testament to the fact that we’d rather build elaborate workarounds for thirty years than break backwards compatibility. And you know what? I can’t really argue with that.