C'è un modo per cambiare le variabili d'ambiente di un altro processo in Unix?

Su Unix, c'è un modo in cui un processo può cambiare le variabili d'ambiente di un altro (supponendo che siano tutti eseguiti dallo stesso utente)? Una soluzione generale sarebbe la migliore, ma in caso contrario, che dire del caso specifico in cui uno è figlio dell'altro?

Modifica: che ne dici di tramite gdb?

Tramite gdb:

(gdb) attach process_id

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

(gdb) detach

Questo è un trucco piuttosto brutto e dovrebbe essere fatto solo nel contesto di uno scenario di debug, ovviamente.

Probabilmente puoi farlo tecnicamente (vedi altre risposte), ma potrebbe non aiutarti.

La maggior parte dei programmi si aspetterà che le variabili env non possano essere modificate dall'esterno dopo l'avvio, quindi la maggior parte probabilmente leggerà solo le variabili a cui sono interessati all'avvio e inizializzerà in base a ciò. Quindi cambiarli in seguito non farà alcuna differenza, poiché il programma non li rileggerà mai.

Se hai pubblicato questo come un problema concreto, dovresti probabilmente adottare un approccio diverso. Se fosse solo per curiosità: Bella domanda :-).

Sostanzialmente no. Se si disponeva di privilegi sufficienti (root, o giù di lì) e si è cercato in / dev / kmem (memoria del kernel) e si sono apportate modifiche all'ambiente del processo e se il processo ha effettivamente fatto nuovamente riferimento alla variabile di ambiente in seguito (ovvero, il processo non aveva già preso una copia dell'env var e non stava usando solo quella copia), quindi forse, se sei stato fortunato e intelligente, e il vento soffiava nella giusta direzione e la fase lunare era corretta, forse, potresti ottenere qualcosa.

Citando Jerry Peek:

Non puoi insegnare nuovi trucchi a un vecchio cane.

L'unica cosa che puoi fare è cambiare la variabile d'ambiente del processo figlio prima di avviarlo: ottiene la copia dell'ambiente genitore, mi dispiace.

Vedere http://www.unix.com.ua/orelly/unix/upt/ch06_02.htm per i dettagli.

Solo un commento sulla risposta sull'uso di / proc. Sotto linux / proc è supportato ma, non funziona, non puoi cambiare il /proc/${pid}/environfile, anche se sei root: è assolutamente di sola lettura.

Potrei pensare al modo piuttosto artificioso per farlo, e non funzionerà per processi arbitrari.

Supponi di scrivere la tua libreria condivisa che implementi 'char * getenv'. Quindi, imposti "LD_PRELOAD" o "LD_LIBRARY_PATH" env. vars in modo che entrambi i processi vengano eseguiti con la libreria condivisa precaricata.

In questo modo, avrai essenzialmente il controllo sul codice della funzione "getenv". Quindi, potresti fare tutti i tipi di brutti trucchi. Il tuo "getenv" potrebbe consultare il file di configurazione esterno o il segmento SHM per i valori alternativi di env vars. Oppure puoi eseguire la ricerca / sostituzione regexp sui valori richiesti. O ...

Non riesco a pensare a un modo semplice per farlo per processi in esecuzione arbitrari (anche se sei root), a meno di riscrivere il linker dinamico (ld-linux.so).

Oppure fai in modo che il tuo processo aggiorni un file di configurazione per il nuovo processo e poi:

• eseguire un kill -HUP sul nuovo processo per rileggere il file di configurazione aggiornato, o
• chiedi al processo di controllare il file di configurazione per gli aggiornamenti di tanto in tanto. Se vengono rilevate modifiche, rileggere il file di configurazione.

Non per quanto ne so. In realtà stai cercando di comunicare da un processo a un altro che richiede uno dei metodi IPC (memoria condivisa, semafori, socket, ecc.). Dopo aver ricevuto i dati con uno di questi metodi, è possibile impostare le variabili di ambiente o eseguire altre azioni in modo più diretto.

Se il tuo unix supporta il filesystem / proc, allora è banale LEGGERE l'env: puoi leggere l'ambiente, la riga di comando e molti altri attributi di qualsiasi processo che possiedi in quel modo. Cambiarlo ... Beh, posso pensare a un modo, ma è un'idea CATTIVA.

Il caso più generale ... non lo so, ma dubito che ci sia una risposta portatile.

(Modificato: la mia risposta originale presupponeva che l'OP volesse LEGGERE l'env, non cambiarlo)

UNIX è pieno di comunicazioni tra processi. Controlla se la tua istanza di destinazione ne ha alcuni. Dbus sta diventando uno standard nell'IPC "desktop".

Cambio le variabili d'ambiente all'interno di Awesome window manager usando awesome-client con è un "mittente" Dbus di codice lua.

Non una risposta diretta ma ... Raymond Chen aveva una logica [basata su Windows] su questo solo l'altro giorno : -

... Sebbene ci siano certamente modi non supportati per farlo o modi che funzionano con l'assistenza di un debugger, non c'è nulla che sia supportato per l'accesso programmatico alla riga di comando di un altro processo, almeno niente fornito dal kernel. ...

Il fatto che non ci sia è una conseguenza del principio di non tenere traccia delle informazioni di cui non hai bisogno. Il kernel non ha bisogno di ottenere la riga di comando di un altro processo. Prende la riga di comando passata alla CreateProcessfunzione e la copia nello spazio degli indirizzi del processo avviato, in una posizione in cui la GetCommandLinefunzione può recuperarla. Una volta che il processo può accedere alla propria riga di comando, le responsabilità del kernel sono esaurite.

Poiché la riga di comando viene copiata nello spazio degli indirizzi del processo, il processo potrebbe persino scrivere nella memoria che contiene la riga di comando e modificarla. Se ciò accade, la riga di comando originale viene persa per sempre; l'unica copia nota è stata sovrascritta.

In altre parole, qualsiasi funzionalità del kernel di questo tipo sarebbe

• difficile da implementare
• potenzialmente un problema di sicurezza

Tuttavia, la ragione più probabile è semplicemente che ci sono casi d'uso limitati per tale struttura.

Sembra che putenv non funzioni ora, ma setenv sì . Stavo testando la risposta accettata mentre cercavo di impostare la variabile nella shell corrente senza successo

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

e la variante come funziona:

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