What is the history and purpose of /sbin?
The original meaning of sbin was "statically-linked binaries." That is, binaries that do not need any other files/libraries to perform their duties.
This naturally meant they tended to be "su" (superuser) or "root" used binaries, since most regular non-su binaries required system libraries to function (typically stored on a filesystem that may not be available under adverse conditions). Therefore, since binaries that must work in single-user mode would be statically-linked, and those are the types of binaries sysadmins/root need often, the meaning started to change.
Nowadays, /sbin is largely considered to mean "system binaries" or privileged "su" binaries. For example, the reference, [0] says:
> System administrative programs that are not required until the /usr filesystem has been mounted (i.e., logically attached to the system) during system startup are usually located in /usr/sbin.
This seems to hint at that history, mentioning multiple file systems that need to be mounted, but makes no mention of static linking. I did a quick scan of the articles I could find, and this seemed representative. I cannot find an authoritative source that corroborates my historical account.
Is this an accurate history of /sbin? Can any wizards give us a more complete history, supposing this is directionally-correct, but missing nuance?
[0] http://www.linfo.org/sbin.html
2 comments
[ 4.7 ms ] story [ 17.8 ms ] threadIn my memory of early Unix systems it wasn't a hard standard; some places /sbin wasn't user accessible, some it was.
I cannot recall if the att 3b2 systems had dynamic binaries in /sbin. if there was such a rule, that's the last place id expect it to be seen in the wild; i think in practice at sites it would've eroded by then into more of a "don't let users know these things exist" $PATH convenience.