> Can someone explain to me how shells get their environment variables? I
> thought that the way it works with c shells is that you can set up your
> .login file to set things up for you, then all subsequent shells will
> inherit that environment. The thing is that when I kick off X, none of my
> xterms inherit my initial login's environment. I know that one way is to
> do an xterm -l to force it act as a login shell, but it seems like this is
> an inappropriate way to do it. I would like to have only one login shell,
> but still have my environment correct.
yes, this is usually documented in the shell's manpage. Bash, for
example, has three (or more) files and three or more conditions it uses to
decide what files to use. Tcsh is similar (I don't have csh on my system,
the tcsh bit should be mostly relevant). Here's the 'Startup and
shutdown' section of the tcsh(1) man page:
Startup and shutdown
A login shell begins by executing commands from the system
files /etc/csh.cshrc and /etc/csh.login. It then executes
commands from files in the user's home directory: first
~/.tcshrc (+) or, if ~/.tcshrc is not found, ~/.cshrc,
then ~/.history (or the value of the histfile shell vari-
able), then ~/.login, and finally ~/.cshdirs (or the value
of the dirsfile shell variable) (+). The shell may read
/etc/csh.login before instead of after /etc/csh.cshrc, and
~/.login before instead of after ~/.tcshrc or ~/.cshrc and
~/.history, if so compiled; see the version shell vari-
able. (+)
Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or
~/.cshrc on startup.
Commands like stty(1) and tset(1), which need be run only
once per login, usually go in one's ~/.login file. Users
who need to use the same set of files with both csh(1) and
tcsh can have only a ~/.cshrc which checks for the exis-
tence of the tcsh shell variable (q.v.) before using tcsh-
specific commands, or can have both a ~/.cshrc and a
~/.tcshrc which sources (see the builtin command)
~/.cshrc. The rest of this manual uses `~/.tcshrc' to
mean `~/.tcshrc or, if ~/.tcshrc is not found, ~/.cshrc'.
In the normal case, the shell begins reading commands from
the terminal, prompting with `> '. (Processing of argu-
ments and the use of the shell to process files containing
command scripts are described later.) The shell repeat-
edly reads a line of command input, breaks it into words,
places it on the command history list, parses it and exe-
cutes each command in the line.
One can log out by typing `^D' on an empty line, `logout'
or `login' or via the shell's autologout mechanism (see
the autologout shell variable). When a login shell termi-
nates it sets the logout shell variable to `normal' or
`automatic' as appropriate, then executes commands from
the files /etc/csh.logout and ~/.logout. The shell may
drop DTR on logout if so compiled; see the version shell
variable.
The names of the system login and logout files vary from
system to system for compatibility with different csh(1)
variants; see FILES.
> In a related question, can you write a shell script that changes an
> environment variable pass the lifetime of the script? For example, I want
> to write a script that adds the current path to the search path. Right
> now I have to source the file, but that is almost more work that its
> worth, because I have to type in the path of the script.
no, not really, you can't pass environment from children back to the
parent -- this is a _good_ thing if you think about it.
What I do is write a shell script to 'echo' out the statements I want,
such as (you'll have to translate to csh yourself, I use bourne or equiv):
echo export PATH=$PATH:$1
Then invoke it like this:
eval `append-path /usr/local/bin`
To make this more usefule:
alias append-path='eval `/path/to/append-path \!*`'
now I can just use
append-path /usr/local/bin
and I'm all set
_____________________ _ _ _________________________
Michael Rice |_| Collective |_| http://www.colltech.com
[EMAIL PROTECTED] |_ Technologies _| 8007598888/8019292 pager
Consultant [] [] "The Power Of Many Minds"
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]
