Is there a way to change the environment variables of another process in Unix?

Question

On Unix, is there any way that one process can change another\'s environment variables (assuming they\'re all being run by the same user)? A general solution would be best,

Answer 1

Quoting Jerry Peek:

You can't teach an old dog new tricks.

The only thing you can do is to change the environment variable of the child process before starting it: it gets the copy of the parent environment, sorry.

See http://www.unix.com.ua/orelly/unix/upt/ch06_02.htm for details.

Just a comment on the answer about using /proc. Under linux /proc is supported but, it does not work, you cannot change the /proc/${pid}/environ file, even if you are root: it is absolutely read-only.

Answer 2

Or get your process to update a config file for the new process and then either:

• perform a kill -HUP on the new process to reread the updated config file, or
• have the process check the config file for updates every now and then. If changes are found, then reread the config file.

Answer 3

Not a direct answer but... Raymond Chen had a [Windows-based] rationale around this only the other day :-

... Although there are certainly unsupported ways of doing it or ways that work with the assistance of a debugger, there’s nothing that is supported for programmatic access to another process’s command line, at least nothing provided by the kernel. ...

That there isn’t is a consequence of the principle of not keeping track of information which you don’t need. The kernel has no need to obtain the command line of another process. It takes the command line passed to the CreateProcess function and copies it into the address space of the process being launched, in a location where the GetCommandLine function can retrieve it. Once the process can access its own command line, the kernel’s responsibilities are done.

Since the command line is copied into the process’s address space, the process might even write to the memory that holds the command line and modify it. If that happens, then the original command line is lost forever; the only known copy got overwritten.

In other words, any such kernel facilities would be

• difficult to implement
• potentially a security concern

However the most likely reason is simply that there's limited use cases for such a facility.

Answer 4

It seems that putenv doesn't work now, but setenv does. I was testing the accepted answer while trying to set the variable in the current shell with no success

$] sudo gdb -p $$
(gdb) call putenv("TEST=1234")
$1 = 0
(gdb) call (char*) getenv("TEST")
$2 = 0x0
(gdb) detach
(gdb) quit
$] echo "TEST=$TEST"
TEST=

and the variant how it works:

$] sudo gdb -p $$
(gdb) call (int) setenv("TEST", "1234", 1)
$1 = 0
(gdb) call (char*) getenv("TEST")
$2 = 0x55f19ff5edc0 "1234"
(gdb) detach
(gdb) quit
$] echo "TEST=$TEST"
TEST=1234

Answer 5

Not as far as I know. Really you're trying to communicate from one process to another which calls for one of the IPC methods (shared memory, semaphores, sockets, etc.). Having received data by one of these methods you could then set environment variables or perform other actions more directly.

Answer 6

Via gdb:

(gdb) attach process_id

(gdb) call putenv ("env_var_name=env_var_value")

(gdb) detach

This is quite a nasty hack and should only be done in the context of a debugging scenario, of course.