VDQ : Can I let a user restart Privoxy? -- PS

Longman, Bill longman at sharplabs.com
Mon Mar 21 12:09:16 MST 2005


> On looking at that again, I decided to try "man export" -- and got the
> whole man page for BASH_BUILTINS(1) : Wow! I see why there's 
> a whole book
> just about bash! But I need a translation of the entry for 
> export ... :-(

BT,

Hopefully this will give you a quick idea about export.

<First principles>
When a Unix process runs, it has an "environment" and a command line.
</First principles>

>From your shell prompt, you can see what your current environment (for your
[probably] bash shell) looks like with the "set" command.

Run that now and see what it lists. A whole slew of gobbledygook.

<First principles>
Subprocesses inherit the environment from the parent process.
</First principles>

One thing the shell allows you to do is limit which environment variables
get "exported" to subprocesses. (Subprocesses are any external commands
i.e., not shell builtins, you run from the command line.) Use the "env"
command to see which ones they are. You should notice that the list of
environment variables returned from the "env" command are fewer than the
number of variables listed from the "set" command.

By default, environment variables in the shell are local variables. You have
to manually export them if you want subshells to know about them.

Here's a demo. We'll make two variables, i and j, and only j will be
exported to subshells.

$ set
<a whole list of stuff>
$ env
<a whole list of similar stuff but fewer>
$ i=4
$ j=48
$ set
<a whole list of stuff>
i=4
j=48
$ env
<a whole list of similar stuff but fewer *without* i or j>
$ export j
$ env
<a whole list of similar stuff but fewer now with j only>

Once a variable is exported, you only have to change its value and both
instances change. Of course once the shell is terminated, you'd have to do
this again. That's why we have things like .bashrc and .profile....

Bill


More information about the yellowdog-general mailing list