larry a price wrote:
> what really happens with environment variables, and how are they visible?
Oh, boy. This is a fun one to try to explain coherently. (-:
Every process is started by a parent process. If you're using the
command line, the parent-child relationship is easy to understand --
the shell is the parent of every program you run from that shell.
If you're in a windowed environment, it's less clear which process
launches which.
An environment is a list of name=value pairs. They are character
strings. They live inside the process's memory, so a process can
modify its own environment anyway it wants.
When a process starts a child process, it gives the child its
environment. Most programs simply pass their own environment along
to their children, but there are plenty of exceptions: a shell
only passes along variables that have been exported. /usr/bin/env
allows complete control over a process's environment. All
setuid programs (should) pass a strictly controlled environment
to their children. (*)
Now, login is a setuid program, and it runs in a process just like
everything else (except the kernel). So login builds a complete new
environment for your login shell. So if you set something in a
startup script, that something won't be inherited by users, but
it will be .
There's also the problem that the login processes (or xdm if you use
xdm) aren't descendants of the startup scripts, they're children of
init, process number 1. But even if you set environment variables in
init (by editing the source and recompiling it), login would probably
delete them.
If you want to set an environment variable for all users, your system
probably has files like /etc/profile or /etc/csh.cshrc, which the
shells read at startup time.
> when you say something like
>
> APP_LOG_DIR=/var/log/app/error.log
> export APP_LOG_DIR
>
> that sets the the environment variable for the rest of the current
> session
> and for all sessions spawned by that session, right?
More accurately, it sets the variable for that process and for all
future descendants of that process. If you export a variable
from a script, it only affects that script, not the login shell
that invoked the script.
> also what does the
>
> . /etc/path/to/script
>
> idiom do?
. is a shell built-in that says, "Don't start a new process, but read
this file in the current shell process." That means that environment
variables and other state altering commands (cd, umask, rlimit, ...)
affect the shell that called the script. The csh equivalent is the
"source" builtin.
(*) I'm glossing over the fact that starting a new process isn't quite
the same as executing a new program. For this discussion, I think
we can ignore the distinction. For more info, though, see the
fork(2) and execve(2) man pages.
--
Bob Miller K<bob>
kbobsoft software consulting
http://kbobsoft.com [EMAIL PROTECTED]
