To understand setup files, you need to understand that a shell can run in two modes: as a login shell or a non-login shell.
When you log in to a UNIX system, the login program usually starts a shell for you. The login program sets a special flag (51.9) to tell a shell that it's a login shell.
If the shell doesn't have that flag set, it won't act like a login shell. Opening a new window in a window system may or may not start a login shell - that depends on the configuration. (For example, the command xterm -ls starts a login shell in an xterm window (1.31); xterm +ls starts a non-login shell.) When you connect to a system with programs like ftp and uucp, that usually starts a non-login shell. And a subshell (38.4) is never a login shell.
How can you tell whether your shell is a login shell? Unfortunately for newcomers, the answer is: "it depends." The scheme does make sense - after you get familiar with it, anyway. When you first log in to a system, you want a login shell that sets things like the terminal type (5.2, 5.3). Other shells on the same terminal should be non-login shells - to avoid redoing those one-time-only setup commands. Different shells have their own methods for handling first-time shell invocations vs. later invocations, and that's what the rest of this article is about.
Finally, at the risk of really getting ahead of myself: in all the shells I know of, parenthesis operators (13.7) don't read any setup file. Instead, they start another instance of your current shell. Parentheses are called "subshell operators," but the subshell they start doesn't print a prompt and usually has a short lifetime.
Whew. Read on (I recommend that you read about all of the shells). Then experiment with your shell's setup files until you get things working the way you want them.
The original Bourne shell has one file that it reads when you log in: it's called .profile and is in your home directory. Put all your setup commands there.
The Bourne shell doesn't read .profile when you start a subshell (13.7), though. Subshell setup information has to come from environment variables (6.1) that were set in .profile when you first logged in or from commands you typed since.
C shell users have three shell setup files available:
The .cshrc file is read any time a C shell starts - that includes shell escapes and shell scripts. [1] This is the place to put commands that should run every time you start a shell. For instance, shell variables like cdpath (14.5) and prompt (7.1) should be set here. Aliases (10.2) should, too. Those things aren't passed to subshells through the environment, so they belong in .cshrc.
[1] If you write a csh script, you should probably use the -f option to keep C shell scripts from reading .cshrc. Of course, even better, you probably shouldn't use csh for scripts (47.2).
The .login file is read when you start a login shell. Here's where you should set:
Environment variables (6.1) (which UNIX will pass to subshells automatically)
Commands you want to run every time you log in - checking for mail and news (1.33), running fortune (3.3), checking your calendar for the day, etc.
Note that .cshrc is read before .login.
The shell reads .logout when you end a login shell. Article 2.7 has tips for reading .logout from non-login shells.
The Korn shell is a lot like the Bourne shell.
A
login Korn shell (2.8)
will read the .profile first.
The .profile can set the
ENV (6.3)
environment variable to the pathname of a file
(typically $HOME/.kshrc).
Then
any Korn shell during that login session (including a subshell)
will read the file named by $ENV
as it starts up, before it runs
other commands.
bash is something of a cross between the Bourne and C shells. A login bash will read .bash_profile, .bash_login, or .profile. A bash subshell - but not a login shell - will read a file named .bashrc in your home directory. The shell reads .bash_logout when you end a login shell; you can set a trap (3.2) to handle non-login shells.
tcsh is like the C shell, with one exception: if you put a file named .tcshrc in your home directory, tcsh will read it instead of .cshrc.
-