Even in 1994 this was still common, https://archive.org/details/learningunix0000gard/page/48/mod...
But why does Kernighan, on that same page, mention /usr/bin already being a thing? If /usr is what we would today call /home, why does it have a bin subdir?
Look at row #3.
I note that there's also a bin group. Was /usr/bin mode 1775, and anyone who should be allowed to install binaries (and update/remove their own installed binaries) was made a member of the bin group?
Also, I note that there's no sbin user. (There is, however, a sys user. But only on Linux, not on BSD...)
The invention of /sbin/ /usr/sbin is all R4, see https://archive.org/details/unixsystemvrelea0000unse_t8i3/pa...
Unix 1980s history is a complicated mess ... that's why there were multiple conflicting standards groups that tried to fix it. The X/Open group had the "single unix specification" which is different from POSIX and say, the Open software foundation (which did OSF/1). Here's a nice crash course: https://en.wikipedia.org/wiki/Single_UNIX_Specification
Explaining the history with the motivations is probably around 10,000 words. AFAIK it hasn't been written. I'd be one of the handful of wackos who'd actually do that and I haven't seen it.
None of the mainstream distributions create nor manage that directory for you.
Quoting https://specifications.freedesktop.org/basedir-spec/basedir-... :
> User-specific executable files may be stored in $HOME/.local/bin. Distributions should ensure this directory shows up in the UNIX $PATH environment variable, at an appropriate place.
Still, I haven't seen any distro create or put it in PATH in the 24 years I've been running Linux.
Also, language package ecosystem tooling — the one thing most people touch that could end up installing user-local binaries — is generally just lame and doesn't obey XDG. For just one example, "per-user global" installation of Ruby gems (`gem install --user-install foo`), should properly install the gems under ~/.local/libexec/gem, and then symlink the binstubs of said gem into ~/.local/bin. But it doesn't; it just dumps everything into its own ~/.gem dir and then expects you-the-user to figure out what dir under there to add to your $PATH. Same applies to Rust, Go, Python, and every other language I'm aware of.
One thing you can do that will almost-assuredly use ~/.local/bin/, though, is to intentionally point an autotools configure script at ~/.local as its --prefix. `make install` will then dump binaries into ~/.local/bin.
The idea is that if a user needs some kind of software and is able to build it autonomously then they can set $PATH and other environment variables to make it available to the session. Please note that in ~/.local there are bin, man, lib and other directories, so you can pretty much build, install and run what you need without bothering your sysadmin :)
These days… some package managers might put stuff in there so that they can work without needing root permission and without messing up with the general system.
That was retconned, actually. My understanding is that the original "/usr" was a second RK05 disk pack added to an early system at Bell Labs for storing stuff owned/created/managed by "users" instead of the system folks. Space was precious in those days and RAID was still a decade in the future. You got your 2MB and had to decide where to mount it and what to put there.
Early Unix filesystems were an ad-hoc wreck, basically. Sun cleaned this up a lot as they moved (or tried to move) to NFS as the primary filesystem for workgroup installations, which is where we get the modern ideas from that you are tagging "historical". I believe (but am not sure) that "sbin" hails from this era.
Then Red Hat came by another decade later and further symmetrized the rules, but in the process essentially obsoleted the distinction between "/" and "/usr", etc...
> Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. ...
> Originally, /sbin binaries were kept in /etc. ...
> Deciding what things go into "sbin" directories is simple: if a normal (not a system administrator) user will ever run it directly, then it must be placed in one of the "bin" directories. Ordinary users should not have to place any of the sbin directories in their path.
I don't think it was a security thing, more a usability thing? Why see "reboot" on your path when you can't use it?
Why did you go to so much effort to avoid typing 'usr'?
(And bevcause GNU autotools uses the variable $PREFIX to abstract away the differences between these — you can `./configure --prefix=/usr` or `./configure --prefix=$HOME/.local` if you like.)
And the fact that "bin dir" is used that way, to group together both bins and sbins, is is why I didn't say "bin dirs vs sbin dirs." (Note how the prior sentence reads really oddly?)
Putting them each in quotation marks — "bin" vs "sbin" — requires some annoying footwork if you expect you'll need to put larger sections of the paragraph in quotation marks. Most editorial guidelines discourage writers from using quotation marks to mention jargon terms for this reason — especially if the terms will be coming up more than once in a piece.
"/bin vs /sbin" sounds like I'm talking specifically about the ones under /, rather than all of them.
"./bin vs ./sbin" just sounds like I got confused and am talking about something that isn't actually the subject of the parent post.
".../bin vs .../sbin" is pretty good — but "..." here is just doing the same thing "$PREFIX" does but with less guidance as to how it should be interpreted — less ability to Google what it means.
Trust me, I considered every option before settling on writing something as silly as "$PREFIX/bin". "$PREFIX/bin" is weird, but clear. And without an elegant best option, the "weird but clear" option is generally the one you should choose in technical writing. People can't generally call you 20 years later to help parse through a sentence that conflates three different usages of a term, but they can just Google any weird (but well-documented) jargon you've used.
That's just me though. I appreciate the thought you put into your decision as well as your detailed explanation, thank you. I wasn't expecting a detail explanation, but I am always interested in people's reasoning when it's different from mine.
I understand the historical reasoning for the / vs /usr vs /usr/local split —
• / was a mount of the machine vendor's installation-engineering-provided bring-up tape — a tape that could usually be safely unmounted once boot was complete and the kernel + persistent daemons had loaded into RAM. (We still have something akin to this in Linux land in the form of the initramfs!)
• /usr was a read-only-mounted OS distribution, either spooled onto the same tape drive that had been reading the rootfs tape a moment before, or (later) over NFS from a high-read-IOPS shared disk server, where in either case the mountpoint was expected to never go away while the OS was running, and therefore the loader could spawn binaries from here using flushable memory-mapped disk IO (allowing far more running processes to fit within the machine's limited memory — important for time-sharing!);
• /usr/local was a separate site-specific mount of stuff added by the local sysadmin — often created as a separate "tacked on the end" partition on the OS distribution tape (you could just attach more tape on the end of the reel, and then format it!) Later, once machine-local hard disks were a thing but Unix systems were still generally mounting /usr over NFS, /usr/local evolved to be the read-only partition of the machine-local HD (and such systems gained a matching read-write local-disk partition, /var.)
But $PREFIX/bin and $PREFIX/sbin were, as far as I know, always just regular directories under the same $PREFIX-level mountpoint, never separate mountpoints of their own.
The only difference I can even think of between a $PREFIX/bin and a $PREFIX/sbin dir, is that the $PREFIX/sbin dir wasn't in $PATH for most users. But surely that was never a real line of defense for security?