BTW, there exist a pair of programs/scripts in Gobolinux that provide the possibility of putting program dirs in arbitrary places. DetachProgram and AttachProgram.
The first allow you to move a directory out of /Programs. The second symlinks a detached directory to /Programs.
While i have yet to try it, i think these could be used to provide something akin to the /bin /usr/bin split on Gobolinux.
http://www.gnu.org/software/bash/manual/html_node/Bash-Start...
.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.
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.
That may explain why so many github projects recommend adding PATH and other env variables to .bash_profile.
[1]https://shreevatsa.wordpress.com/2008/03/30/zshbash-startup-...
http://lists.busybox.net/pipermail/busybox/2010-December/074...
I make everyone I hire and/or work with read it.
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:
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.
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.
Well, he doesn't have to wait anymore:
https://trac.macports.org/wiki/FAQ#defaultprefix
>Why is /opt/local the default install location for MacPorts?
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.
/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:
