Есть ли способ изменить переменные среды другого процесса в Unix?

Есть ли в Unix способ, которым один процесс может изменить переменные среды другого (при условии, что все они запускаются одним и тем же пользователем)? Общее решение было бы лучше всего, но если нет, как насчет конкретного случая, когда один из них является потомком другого?

Изменить: как насчет через GDB?

Через GDB:

(gdb) attach process_id

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

(gdb) detach

Это довольно неприятный прием, и его, конечно, следует делать только в контексте сценария отладки.

Вы, вероятно, можете сделать это технически (см. Другие ответы), но это может вам не помочь.

Большинство программ ожидают, что переменные окружения не могут быть изменены извне после запуска, поэтому большинство, вероятно, просто прочитают переменные, которые им интересны, при запуске и инициализируются на основе этого. Так что изменение их впоследствии не имеет значения, поскольку программа никогда их не перечитает.

Если вы разместили это как конкретную проблему, вам, вероятно, следует использовать другой подход. Если бы это было просто из любопытства: Хороший вопрос :-).

По сути, нет. Если у вас были достаточные привилегии (root или около того) и вы копались в / dev / kmem (память ядра), и вы внесли изменения в среду процесса, и если процесс действительно впоследствии повторно ссылался на переменную среды (то есть процесс еще не сделал копию env var и не использовал только эту копию), тогда, возможно, если вам повезло и умен, и ветер дул в правильном направлении, и фаза луны была правильной, возможно, вы могли бы чего-то добиться.

Цитата Джерри Пика:

Нельзя научить старую собаку новым трюкам.

Единственное, что вы можете сделать, это изменить переменную окружения дочернего процесса перед его запуском: он получает копию родительского окружения, извините.

Подробнее см. Http://www.unix.com.ua/orelly/unix/upt/ch06_02.htm .

Просто комментарий к ответу об использовании / proc. В linux / proc поддерживается, но он не работает, вы не можете изменить /proc/${pid}/environфайл, даже если вы root: он абсолютно доступен только для чтения.

Я мог бы придумать довольно надуманный способ сделать это, и он не будет работать для произвольных процессов.

Предположим, вы пишете свою собственную разделяемую библиотеку, которая реализует char * getenv. Затем вы настраиваете "LD_PRELOAD" или "LD_LIBRARY_PATH" env. vars, чтобы оба процесса запускались с предварительно загруженной общей библиотекой.

Таким образом, у вас будет практически полный контроль над кодом функции getenv. Тогда вы сможете проделывать всевозможные неприятные трюки. Ваш 'getenv' может обращаться к внешнему файлу конфигурации или сегменту SHM для получения альтернативных значений переменных env. Или вы можете выполнить поиск / замену регулярного выражения для запрошенных значений. Или ...

Я не могу придумать простой способ сделать это для произвольных запущенных процессов (даже если вы - root), кроме как переписать динамический компоновщик (ld-linux.so).

Или попросите свой процесс обновить файл конфигурации для нового процесса, а затем либо:

• выполнить kill -HUP для нового процесса, чтобы перечитать обновленный файл конфигурации, или
• пусть процесс время от времени проверяет файл конфигурации на наличие обновлений. Если изменения обнаружены, то перечитайте файл конфигурации.

Насколько я знаю, нет. На самом деле вы пытаетесь взаимодействовать от одного процесса к другому, который вызывает один из методов IPC (общая память, семафоры, сокеты и т. Д.). Получив данные одним из этих методов, вы можете затем установить переменные среды или выполнить другие действия более напрямую.

Кажется, что putenv сейчас не работает, а setenv работает. Я тестировал принятый ответ, безуспешно пытаясь установить переменную в текущей оболочке

$] 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=

и вариант, как это работает:

$] 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

Если ваш unix поддерживает файловую систему / proc, то ПРОЧИТАТЬ env тривиально - таким образом вы можете читать среду, командную строку и многие другие атрибуты любого процесса, которым вы владеете. Изменить это ... Ну, я могу придумать способ, но это ПЛОХАЯ идея.

Более общий случай ... Я не знаю, но сомневаюсь, что есть переносимый ответ.

(Отредактировано: мой первоначальный ответ предполагал, что OP хочет ПРОЧИТАТЬ env, а не изменять его)

UNIX полон межпроцессного взаимодействия. Проверьте, есть ли у вашего целевого экземпляра. Dbus становится стандартом в «настольных» IPC.

Я меняю переменные окружения внутри оконного менеджера Awesome, используя awesome-client с Dbus "отправителем" кода lua.

Не прямой ответ, но ... Рэймонд Чен только на днях обосновал это [на основе Windows] : -

... Хотя, безусловно, существуют неподдерживаемые способы сделать это или способы, которые работают с помощью отладчика, нет ничего, что поддерживается для программного доступа к командной строке другого процесса, по крайней мере, ничего не предусмотрено ядром. ...

То, что нет, является следствием принципа отказа от отслеживания информации, которая вам не нужна. Ядру нет необходимости получать командную строку другого процесса. Он берет командную строку, переданную CreateProcessфункции, и копирует ее в адресное пространство запускаемого процесса в место, откуда GetCommandLineфункция может ее получить. Как только процесс получает доступ к собственной командной строке, все обязанности ядра выполняются.

Поскольку командная строка копируется в адресное пространство процесса, процесс может даже записывать в память, содержащую командную строку, и изменять ее. Если это произойдет, исходная командная строка будет потеряна навсегда; единственная известная копия была перезаписана.

Другими словами, любые такие средства ядра будут

• сложно реализовать
• потенциально проблема безопасности

Однако наиболее вероятная причина просто в том, что существует ограниченное количество вариантов использования такого средства.