
Understanding the bin, sbin, usr/bin, usr/sbin Split [pdf] - Somasis
http://landley.net/writing/hackermonthly-issue022-pg33.pdf
======
bobba
Can we also address .bash_rc, .bash_profile, .profile, /etc/bash.bashrc,
disambiguation. I get tired of instructions advising me to put PATH and other
modifiers in .bash_profile when that only works for a login shell. Doesn't
work, as needed, if you are actually using Linux as your desktop system.

~~~
yes_or_gnome
First, it's .bashrc and /etc/bashrc.

[http://www.gnu.org/software/bash/manual/html_node/Bash-
Start...](http://www.gnu.org/software/bash/manual/html_node/Bash-Startup-
Files.html)

.bashrc - is for non-login shells (not run with --login option). This is where
you want to configure your PATH, so all shell invocations behave the same.
You'll likely have the PATH modification as the first line, then you may want
to source the system rc file (/etc/bashrc), and, usually, you'll have some
interactive-only modifications such modifications to PS1.

.bash_profile(, .bash_login, or .profile) - is used for login shells. You may
have some reason to run some commands (personal MTOD!?). There may be good
reason to manipulate PATH here, but I can't think of one. (The rbenv tool from
the Ruby community insists using .bash_profile; I don't know why.) Finally,
you end by sourcing the .bashrc.

~~~
thristian
Environment variables are automatically shared from a parent process to its
child processes, so typically you'd want to set up your environment in
~/.profile (or ~/.bash_profile) so you only have to do the work once. This
includes things like setting $PATH, $LESS, $EDITOR, $LS_COLORS and so forth.

On the other hand, things like shell aliases are _not_ automatically shared to
child processes, so you need to set them up afresh in every shell you launch.
Therefore, ~/.bashrc is the place for those things.

~~~
lloydde
> typically you'd want to set up your environment in ~/.profile (or
> ~/.bash_profile)

It's an early optimization, that generally no longer is worth the complexity.
I put everything in .bashrc. I'm more likely to break out a separate
environment shell file by related or complex tasks to assist in
testing/debugging my environment.

------
ghshephard
I personally like the differentiation between /sbin (71 files) and /usr/sbin
(195 files) on OpenBSD and /bin (42 files) and /usr/bin (336 files).

I don't know if it's still the case, but at one point, everything required to
boot up a system, and get to a ksh prompt, was in /sbin and /bin, and the only
purpose for commands in /usr was for user interaction.

When mentally modelling the purpose of the commands, it was nice to have that
differentiation, particular the "Stuff in /usr is really for the user only,
not needed to boot a system."

Of course, I have no idea whether that still holds true - but it's still a
good starting point.

~~~
ben_bai
Yes, it's still true. /(s)bin is for booting a minimal system i.e. for
maintainance and those binaries are statically linked. /usr/(s)bin is the rest
of the base system. /usr/local/(s)bin is for packages/ports.

------
cremno
>I’m still waiting for /opt/local to show up...

Well, he doesn't have to wait anymore:

[https://trac.macports.org/wiki/FAQ#defaultprefix](https://trac.macports.org/wiki/FAQ#defaultprefix)

>Why is /opt/local the default install location for MacPorts?

------
frik
There are/were small Linux distro that fit on a 3.5" floppy diskette. I
remember one that required just a single floppy disk to boot and a later
version came with a second floppy with additional applications. So the bin
/usr/bin split was still useful in the early Linux era (I used such a floppy
Linux til 2002 for misc purposes). A starting point:
[http://superuser.com/questions/130457/what-linux-fits-on-
a-f...](http://superuser.com/questions/130457/what-linux-fits-on-a-floppy-
disk)

------
egwynn
The reasons for the complexity are lame, but sometimes there are nice
consequences. For instance, on FreeBSD you can pretty much just nuke _/
usr/local/_ and be left with a functional base-system (broken configs
notwithstanding).

------
ChuckMcM
Interesting rant. Actually in 1990 people were complaining that SunOS took up
too much disk space (well they always complained but whatever). And C (and
unix) always had something of a naming / packaging problem.

Of course long after the size of disks were "big enough" to hold everything in
/ putting things on different drives gave you more disk I/O's to play with and
improved overall system performance. If you could get small drives today you
could play with that yourself but it seems silly to have a 500GB disk mounted
on /var/log :-).

But more importantly for me over the years was putting the "OS" required user
land stuff in one place and the "rest" of it in another place meant I could
replace the kernel and userland code independently of restoring home
directories and what not. These days I do that by mounting "my" stuff via NFS
and making my servers basically completely replaceable with a re-imaging.

------
brandonmenc
The original version:

[http://lists.busybox.net/pipermail/busybox/2010-December/074...](http://lists.busybox.net/pipermail/busybox/2010-December/074114.html)

I make everyone I hire and/or work with read it.

~~~
DougMerritt
Unfortunate, considering a lot of it is wrong. "Just so" stories (a term from
Kipling) are appealing and yet historically incorrect.

For instance, /sbin and /usr/sbin/ did not exist in the 1970s at all, let
alone in the early 1970s.

I'm not sure exactly which system it first appeared in, but on BSD, which
originally was add-ons to the Bell Labs distribution, it was not present in
the 1986 4.3 BSD but did appear in the 1993 4.4 BSD.

You can verify that, and search for it on other early Unixes, here, for
instance:

[http://minnie.tuhs.org/cgi-bin/utree.pl](http://minnie.tuhs.org/cgi-
bin/utree.pl)

~~~
brandonmenc
OK, it gets a couple small details wrong, but the rest appears to be true -
that /usr was added for want of disk space and /sbin was for statically linked
binaries.

The point of passing this along is to show that some ingrained "truths" (ex:
sbin is for system binaries!) are just historical artifacts of conditions that
no longer apply.

------
GutenYe
Well, Arch Linux simplify them all, everything is in usr/bin and others just
symlink to usr/bin.

~~~
vezzy-fnord
I believe Fedora was the first to begin this trend.

~~~
4ad
Solaris did it first.

~~~
digi_owl
It seems like Fedora is driving Linux towards a half and half between Solaris
and OSX. I would not care either way, except choices are being removed or made
difficult in the process.

------
DougMerritt
It gets the /sbin part wrong.

/sbin and /usr/sbin/ did not exist in the 1970s at all, let alone in the early
1970s.

I'm not sure exactly which system it first appeared in, but on BSD, which
originally was add-ons to the Bell Labs distribution, it was not present in
the 1986 4.3 BSD but did appear in the 1993 4.4 BSD.

You can verify that, and search for it on other early Unixes, here, for
instance:

[http://minnie.tuhs.org/cgi-bin/utree.pl](http://minnie.tuhs.org/cgi-
bin/utree.pl)

------
davidw
See also: Filesystem Hierarchy Standard:

[https://wiki.debian.org/FilesystemHierarchyStandard](https://wiki.debian.org/FilesystemHierarchyStandard)

