How to modify the environment of the parent process?
Tom Nolette
settings of the parent process?
For example if I execute this shell script, which I will call "setme"
#! /bin/csh -f
setenv THIS "this is set"
setenv THAT "that is set"
exit 0
Now if I type "setme" on in a TCSH or CSH shell, the environment settings
of THIS and THAT are not visible to the current (parent) shell, only to
the /bin/csh process spawned as a child.
If I type "source setme" then I get the desired effect, THIS and THAT are
now active in the shell, since there was no child spawned.
What I want to do spawn a child and get the same thing.
I have heard of a "module" that can do this, for example "module load
xxxx"
"module unload xxxx". I'm looking for a way to do this by a script or
better
yet, some C source code..... without using "modules" ....
Right now I have store these settings to a file for later use, very
kludgey....
Please help!
Regards,
Tom
tom.n...@analog.com
John Gordon,217-352-6511x7418,CEERD-CF-N
> Is it possible to execute a script or binary to modify the environment
> settings of the parent process?
no.
> If I type "source setme" then I get the desired effect, THIS and THAT are
> now active in the shell, since there was no child spawned.
yes.
> I have heard of a "module" that can do this, for example "module load
> xxxx"
sounds like "module" is much like "source".
---
"She even named one city after Robert, her ex-boyfriend, just to annoy
me. I have it in a saved game on my laptop. Every now and then I boot
it up just to let Robertville starve itself off the map." -- Tom Chick
Kurtis D. Rader
> Is it possible to execute a script or binary to modify the environment
> settings of the parent process?
No. This is intentional. Allowing arbitrary processes to modify their parent
process environment is a security nightmare, not to mention an operational
nightmare. Do you really want changes made by a program to its environment,
for purposes of influencing a child process, to be automatically reflected
in the parent's environment? I certainly do not. The current model is far
more useful 99% of the time than the behavioral model you desire.
> Right now I have store these settings to a file for later use, very
> kludgey....
What's kludgey about it? You're explicitely defining a protocol by which one
process can modify the environment of a different process. Of course, whether
or not the use of an intermediate temporary file is the appropriate mechanism
is subject to debate. But in any event you definitely want a mechanism that
requires the explicit cooperation of the parent process.
Pascal Bourguignon
"Kurtis D. Rader" <kra...@aracnet.com> writes:
> On Thu, 23 May 2002 13:25:02 -0700, Tom Nolette wrote:
>
> > Is it possible to execute a script or binary to modify the environment
> > settings of the parent process?
>
> No. This is intentional. Allowing arbitrary processes to modify their parent
> process environment is a security nightmare, not to mention an operational
> nightmare. Do you really want changes made by a program to its environment,
> for purposes of influencing a child process, to be automatically reflected
> in the parent's environment? I certainly do not. The current model is far
> more useful 99% of the time than the behavioral model you desire.
I'm wondering. There's so many rookies asking for this feature,
perhaps we could implement it just for the fun of seeing them shooting
themselves in the foot.
It should be easy enough to implement using the same facilities that
gdb uses when it attaches to any process of the user.
Well, actually, remembering my own rooky years, I'd say that the
problem comes from the confusion we may do, taking environment
variables for mere programming language variables, as shell syntax
purports. In addition, the name of the command "export" in Bourne
shells does exactly the opposite of the "export" statements in
languages such as Modula-2, Modula-3, etc. (setenv of csh is better
choosen).
What should be realised early, is that when we need to do anything
more complex than starting a program, as soon as we need to store or
refer "variables', we need to have a true programming language, and
forget shells. I'd use scsh. Some prefer perl.
> > Right now I have store these settings to a file for later use, very
> > kludgey....
>
> What's kludgey about it? You're explicitely defining a protocol by which one
> process can modify the environment of a different process. Of course, whether
> or not the use of an intermediate temporary file is the appropriate mechanism
> is subject to debate. But in any event you definitely want a mechanism that
> requires the explicit cooperation of the parent process.
--
__Pascal_Bourguignon__
Kurtis D. Rader
> I'm wondering. There's so many rookies asking for this feature,
> perhaps we could implement it just for the fun of seeing them shooting
> themselves in the foot.
Since I provide software support for UNIX (I'm a systems support engineer for
IBM) I can't decide whether to applaud the suggestion or hire a hit man :-) It
would mean more work for my team which is never a bad thing (it's how I earn
my living, after all). But if we start implementing "features" like this
pretty soon UNIX will start to look like MS Windows :-)
> It should be easy enough to implement using the same facilities that gdb
> uses when it attaches to any process of the user.
Actually, this cannot be done on any flavor of UNIX I'm familiar with. It
would require a backwards incompatible change to how environmental variables
are implemented. Today those strings are part of the address space of the
process. Which means that modifying the environment of a running process
requires modifying its address space. You definitely do not want another
process, running asynchronously to yours, to be updating your address space.
The ability of a process to modify another processes environment variables
would require that they be stored in kernel memory and readable/writable only
via system calls in order to be able to synchronize updates and reads of those
strings by multiple processes.
Lew Pitcher
>
> On Fri, 24 May 2002 00:38:27 -0700, Pascal Bourguignon wrote:
>
> > I'm wondering. There's so many rookies asking for this feature,
> > perhaps we could implement it just for the fun of seeing them shooting
> > themselves in the foot.
>
> Since I provide software support for UNIX (I'm a systems support engineer for
> IBM) I can't decide whether to applaud the suggestion or hire a hit man :-) It
> would mean more work for my team which is never a bad thing (it's how I earn
> my living, after all). But if we start implementing "features" like this
> pretty soon UNIX will start to look like MS Windows :-)
>
> > It should be easy enough to implement using the same facilities that gdb
> > uses when it attaches to any process of the user.
>
> Actually, this cannot be done on any flavor of UNIX I'm familiar with. It
> would require a backwards incompatible change to how environmental variables
> are implemented. Today those strings are part of the address space of the
> process. Which means that modifying the environment of a running process
> requires modifying its address space.
Couldn't this be done by putting the environment variables into a shared
memory block?
With each process in a process group sharing the memory block, and
co-ordinating access/update using semaphors, you _could_ get the same
effect as MSDOS gives.
I'm not suggesting that we _do_ this, of course.
> You definitely do not want another
> process, running asynchronously to yours, to be updating your address space.
> The ability of a process to modify another processes environment variables
> would require that they be stored in kernel memory and readable/writable only
Not necessarily in kernel memory, but certainly in kernel-controlled
memory
> via system calls in order to be able to synchronize updates and reads of those
> strings by multiple processes.
semctl(2) et al, shmctl(2) et al
--
Lew Pitcher
Master Codewright and JOAT-in-training
Registered (Slackware) Linux User #112576 (http://counter.li.org/)
David Schwartz
> Couldn't this be done by putting the environment variables into a shared
> memory block?
There are any number of ways that one process can change the
environment of another process if both processes cooperate.
DS
Kurtis D. Rader
> Couldn't this be done by putting the environment variables into a shared
> memory block?
>
> With each process in a process group sharing the memory block, and
> co-ordinating access/update using semaphors, you _could_ get the same effect
> as MSDOS gives.
Sure, but that is also a backward incompatible change and arguably carries
more risk. Furthermore, it's not clear how this would work in practice given
other UNIX semantics.
Consider the following scenario. You start a process from the login shell
(perhaps it is launched from .profile or one of its kin). You then realize
that its environment needs to be changed. So you start another interactive
session. The two sessions are not related except that the real uid of the
processes is the same. Note that your new login shell and the original
application process are not in the same process group (using the normal
definition of that term). So the only way to modify the original process
environment from the new shell is via one or more system calls. Certainly that
system call could do nothing more than arrange for an address range to be
shared by the processes. The remainder of the work can be done entirely with
user mode code. But since you have to make at least one system call in any
event why not let the kernel do the entire job? It's far easier for the kernel
to coordinate the update since it can directly affect the state of each
process.
Consider another case. How do you handle growing the environment? It may not
be possible to simply extend the length of the shared address range. Some of
the processes may have established other mappings that make doing so
impossible. Again, this is much easier to handle if we let the kernel manage
the storage.
Dan Mercer
>
>> Couldn't this be done by putting the environment variables into a shared
>> memory block?
>>
>> With each process in a process group sharing the memory block, and
>> co-ordinating access/update using semaphors, you _could_ get the same effect
>> as MSDOS gives.
>
> Sure, but that is also a backward incompatible change and arguably carries
> more risk. Furthermore, it's not clear how this would work in practice given
> other UNIX semantics.
>
And consider this - that the only people who would want this facility
don't know how to design code in the first place.
DELETIA
--
Dan Mercer
dame...@mmm.com
Opinions expressed herein are my own and may not represent those of my employer.