Actually, they are fairly simple. A case in point is the basic Korn shell behaviour. * There are two scripts run by a login shell, $HOME/.profile and /etc/pro

Actually, they are fairly simple. A case in point is the basic Korn shell behaviour. * There are two scripts run by a login shell, $HOME/.profile and /etc/profile . * These scripts set up environment variables and other things (e.g. umask) to be inherited by the whole login session. * They, specifically, optionally set an ENV variable whose value names a third script that is run by every interactive shell, including the interactive login shell. That's exactly three scripts: one for the system administrator and another one for the user to set up login-session-wide stuff, and one for the user to set up this-interactive-shell stuff (such as the shell variables for fancy prompts, completion settings, command-line editing stuff, useful interactive shell aliases, and whatnot). They are always in the same order. And they are simply based upon two things: whether the shell is a login shell, and whether the shell is an interactive shell. The C shell mechanism is similarly simple, on its own. The complexity mainly comes from the fact that the Bourne Again shell and the Z shell, amongst others, have multiple mechanisms mixed together and extensions. They look for scripts that are specifically in their own shell languages rather than potentially shared with other shells; .zprofile and .bash_profile instead/ahead of .profile , for example. They have extra scripts that mirror the C shell way of doing things; .zlogin, .zlogout, .bash_login, .bash_logout, .bashrc, and .zshrc, for example. They have idiosyncratic and non-strictly-standard ways of deciding what constitutes an interactive shell. They have mechanisms for disabling the extensions, and ways to come up in alternative not-strictly-conformant sh-compatible modes.