Changer une variable d'environnement du shell de login

Le
Rémi Moyen
Bonjour,

Comment est-ce que je peux faire pour changer la valeur d'une variable
d'environnement qui est définie dans le shell de login, sous X ?

(en fait je me rends compte que ma question a aussi sa place dans
fca.x11, donc x-post, je laisse le suivi ici)

Par exemple, j'utilise cervisia pour accéder à des bases CVS. Si je
lance cervisia depuis par exemple un menu (j'utilise KDE, mais ca
devrait être indépendant du window manager, tout ca), CVSROOT,
CVSSERVER et autres ont une certaine valeur, définie dans mes scripts
de login (.login et autres). OK.

Mais si je décide soudainement de changer, disons, CVS_RSH (parce que
j'ai oublié de mettre ssh, rahzut), est-ce que je peux faire ce
changement de telle sorte que si je relance ensuite cervisia depuis un
menu, il utilise cette nouvelle valeur ? Il faudrait donc que je
modifie la valeur de cette variable dans le shell de login, mais
comment ?

(j'ai pris l'exemple de cervisia mais c'est juste un exemple -- je
suis curieux de savoir de manière globale si il est possible de
changer l'environnement du shell de login. Ceci étant, si il existe
dans cervisia une option pour changer directement les variables
d'environnement, ca m'intéresse aussi de le savoir !)

Je peux évidemment changer ma variable dans un xterm et lancer
cervisia depuis ce xterm. Mais c'est pas très propre (parce que si
plus tard dans ma session je vais oublier dans quel xterm j'avais fait
ce changement et que j'ai la flemme de le faire dans tous mes
terms !). Bien sûr, je peux me délogguer/relogguer (après avoir remis
ma nouvelle valeur dans un script de login), mais bon, c'est un peu
bourrin comme solution

Est-ce que quelqu'un a une autre idée ?

Merci d'avance !
--
Rémi Moyen
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #16524991
Rémi Moyen wrote in message
Comment est-ce que je peux faire pour changer la valeur d'une variable
d'environnement qui est définie dans le shell de login, sous X ?



La réponse à ta question :

Tu tapes Ctrl-Meta-F1, ou l'équivalent sur ton système, pour repasser sur
ton shell de login. Éventuellement Ctrl-Z puis bg pour passer ta session X11
en arrière plan, et tu tapes les commandes que tu veux dans ton shell de
login.

Mais ce n'est certainement pas la réponse à la question que tu te poses.

Mais si je décide soudainement de changer, disons, CVS_RSH (parce que
j'ai oublié de mettre ssh, rahzut), est-ce que je peux faire ce
changement de telle sorte que si je relance ensuite cervisia depuis un
menu, il utilise cette nouvelle valeur ? Il faudrait donc que je
modifie la valeur de cette variable dans le shell de login, mais
comment ?



Non, absolument pas. Le shell de login n'a strictement rien à voir.
D'ailleurs, il y a de bonnes chances pour qu'il n'y en ait jamais eu, de
shell de login, si tu t'es connecté par un display manager quelconque.

Il y a deux solutions pour que ton cervisia ait la variable d'environnement
qui t'intéresse.

La méthode « passive » : cervisia hérite de l'environnement qui lui est
fourni par le programme qui le lance, qui est probablement (mais pas
forcément) le programme qui affiche le menu. Tu consultes donc la doc de ce
programme pour savoir comment changer l'environnement des trucs qu'il lance.

Par exemple, avec Fvwm, ça peut se faire avec la directive SetEnv, qui peut
par exemple être appelée par le biais de FvwmCommand, si FvwmCommandS est
lancé.

La méthode « active » : tu intercales, entre le programme qui lance cervisia
et cervisia lui-même un élément qui te permet de contrôler l'environnement.
Typiquement, un script shell : tu configures le menu pour lancer
cervisia-env, qui est un script qui définit l'environnement puis exécute
cervisia (ne pas oublier le « exec »). Pour changer l'environnement, tu
changes le script, ou bien tu fais un script assez intelligent pour aller
chercher son environnement ailleurs.

Il y aurait une variante de cette méthode en contrôlant finement le shell
qui est probablement invoqué pour lancer cervisia, mais il est très facile
de ruiner complètement sa configuration en l'utilisant sans savoir
exactement ce qu'on fait, donc je ne vais pas en parler.
Rémi Moyen
Le #16525091
On Aug 11, 4:18 pm, Nicolas George
> Comment est-ce que je peux faire pour changer la valeur d'une variable
> d'environnement qui est définie dans le shell de login, sous X ?

La réponse à ta question :

Tu tapes Ctrl-Meta-F1, ou l'équivalent sur ton système, pour repasser sur
ton shell de login. Éventuellement Ctrl-Z puis bg pour passer ta sessio n X11
en arrière plan, et tu tapes les commandes que tu veux dans ton shell d e
login.

Mais ce n'est certainement pas la réponse à la question que tu te pos es.



Non, en effet. D'autant plus que comme tu t'en doutes, j'utilise un
display manager donc je ne suis pas loggué en console.

Non, absolument pas. Le shell de login n'a strictement rien à voir.
D'ailleurs, il y a de bonnes chances pour qu'il n'y en ait jamais eu, de
shell de login, si tu t'es connecté par un display manager quelconque.



Ah zut, c'est ce que je pensais... Pourtant, quand je regarde un les
processus qui tournent une fois que je suis loggué (via gdm, en
l'occurence), j'ai entre autres :
-/bin/csh -c /usr/bin/dbus-launch --exit-with-session /home/
moyen/.Xclients
qui lui-même ensuite lance /usr/bin/startkde, qui est apparamment un
script qui lance dcop, kdeinit et autre bazar kde-esque (et kwin a
l'air d'être lancé par kdeinit).
Et ce shell a pour parent "/usr/bin/gdm-binary -nodaemon".

J'avais interprété ca comme "gdm lance un shell de login (qui lance
startkde, entre autres)" (et gdm lance aussi X à côté, d'ailleurs),
mais je me plante sans doute.

En fait et à la réflexion, je crois que je me suis planté dès le d ébut
en supposant que KDE (ou n'importe quel autre WM, dans ma tête)
utilisait un shell particulier pour lancer les programmes. C'est
logique que ce ne soit pas le cas, comme tu l'expliques... Et que j'ai
un shell de login ou pas ne change rien à la question, en fait, ce qui
compte c'est l'environnement du processus parent et c'est tout.

En fait ce que je cherche, au final, c'est comment modifier une
variable de l'environnement de kdeinit/kwin/kmenu/k-truc-chose-
chouette...

De manière plus globale et par curiosité, est-ce qu'il existe un moyen
pour modifier l'environnement d'un processus qui est déjà en train de
tourner (par une méthode "externe" au processus en question, bien
sûr) ? Genre "hack-env <pid> PATH /the/new/path/:/in/place/of/the/old/
one" ?

La méthode « active » : tu intercales, entre le programme qui lance cervisia
et cervisia lui-même un élément qui te permet de contrôler l'envi ronnement.



Oui, mais ca c'est quand même valable uniquement quand tu sais à
l'avance pour quel(s) programme(s) tu vas vouloir changer des
variables. Ou alors il faut dupliquer toutes les entrées de tous les
menus (et idem pour toutes les méthodes de lancement de commandes
spécifiques au WM, icônes ou autres...) pour pouvoir ensuite
bidouiller les variables à la demande. Bon évidemment, si ca ne
concerne qu'une seule appli (ou quelques unes), rien à dire.

Merci pour ta réponse !
--
Rémi Moyen
Stephane CHAZELAS
Le #16525191
2008-08-11, 07:59(-07), Rémi Moyen:
Comment est-ce que je peux faire pour changer la valeur d'une variable
d'environnement qui est définie dans le shell de login, sous X ?


[...]

Seul le process lui-meme peut changer son environement (ou
plutot la liste des variables qu'il passera aux commandes qu'il
executera dans le future).

Si kde n'a pas d'interface où specifier un changement
d'environnement pour les futures commandes, tu peux recourir a
des hack du style:

gdb "$(command -v kdeinit)" << E
attach $(pidof kdeinit)
call putenv("CVS_RSH=ssh")
detach
E

(remplacer pidof par quelquechose de plus adequat).

Voir aussi kshell/kwrapper.

Je ne suis pas sur de pourquoi tu fais reference au shell de
login toutefois.

--
Stéphane
Nicolas George
Le #16525361
Rémi Moyen wrote in message
J'avais interprété ca comme "gdm lance un shell de login



C'est un shell, mais pas un shell de login : un shell de login, c'est le
shell lancé au tout début d'une session texte, et qui en général devient
interactif. Et surtout, ce shell n'a aucune raison de rester là. Le fait
qu'il soit encore là dans l'arborescence des processus est pour moi plus
signe d'un problème de configuration que d'autre chose.

En fait et à la réflexion, je crois que je me suis planté dès le début
en supposant que KDE (ou n'importe quel autre WM, dans ma tête)
utilisait un shell particulier pour lancer les programmes.



Oh, si, il le fait probablement : la plupart des programmes qui invoquent
des commandes saisies par l'utilisateur le font par le biais de « sh -c
commande ». À nouveau, c'est un shell, pas un shell de login.

En fait ce que je cherche, au final, c'est comment modifier une
variable de l'environnement de kdeinit/kwin/kmenu/k-truc-chose-
chouette...



Dans ce cas, c'est dans la doc de ces trucs qu'il faut chercher.

De manière plus globale et par curiosité, est-ce qu'il existe un moyen
pour modifier l'environnement d'un processus qui est déjà en train de
tourner (par une méthode "externe" au processus en question, bien
sûr) ? Genre "hack-env <pid> PATH /the/new/path/:/in/place/of/the/old/
one" ?



Rien de portable.
Rémi Moyen
Le #16529471
On Aug 11, 5:15 pm, Nicolas George
> En fait et à la réflexion, je crois que je me suis planté dès l e début
> en supposant que KDE (ou n'importe quel autre WM, dans ma tête)
> utilisait un shell particulier pour lancer les programmes.

Oh, si, il le fait probablement : la plupart des programmes qui invoque nt
des commandes saisies par l'utilisateur le font par le biais de « sh -c
commande ». À nouveau, c'est un shell, pas un shell de login.



Oui, mais c'est pas le même shell qui est utilisé pour lancer toutes
les commandes. C'est ça que je voulais dire par "un shell particulier"
-- et dans ce cas il aurait suffit de modifier l'environnement de ce
shell-là. Mais je ne vois pas comment ça serait possible de réutilise r
le même shell pour lancer plusieurs commandes. J'aurais dû réfléchi r
un peu plus avant de poser ma question...

> En fait ce que je cherche, au final, c'est comment modifier une
> variable de l'environnement de kdeinit/kwin/kmenu/k-truc-chose-
> chouette...

Dans ce cas, c'est dans la doc de ces trucs qu'il faut chercher.



J'ai pas trouvé (en fait, c'est ce que j'avais cherché avant même de
poser ma question), tout ce que j'ai vu c'est comment changer des
variables avant de lancer KDE, pas une fois qu'il est lancé. Mais je
trouve les docs de KDE assez inutiles et style "vous êtes dans un
hélicoptère"... Je vais continuer à chercher et je poserais la
question (ailleurs, ça n'a pas vraiment sa place ici) si je ne trouve
pas.

> De manière plus globale et par curiosité, est-ce qu'il existe un mo yen
> pour modifier l'environnement d'un processus qui est déjà en train de
> tourner (par une méthode "externe" au processus en question, bien
> sûr) ? Genre "hack-env <pid> PATH /the/new/path/:/in/place/of/the/old /
> one" ?

Rien de portable.



OK. Si il n'y a pas mieux que la "méthode" proposée par Stéphane via
gdb, en effet, je ne vais pas m'amuser à jouer avec ça !

Merci de vos réponses !
--
Rémi Moyen
Stephane CHAZELAS
Le #16531771
2008-08-12, 02:36(-07), Rémi Moyen:
[...]
J'ai pas trouvé (en fait, c'est ce que j'avais cherché avant même de
poser ma question), tout ce que j'ai vu c'est comment changer des
variables avant de lancer KDE, pas une fois qu'il est lancé. Mais je
trouve les docs de KDE assez inutiles et style "vous êtes dans un
hélicoptère"... Je vais continuer à chercher et je poserais la
question (ailleurs, ça n'a pas vraiment sa place ici) si je ne trouve
pas.


[...]

Tu peux regarder du coté de kshell/kwrapper(1) et creuser a
partir de la.

> De manière plus globale et par curiosité, est-ce qu'il existe un moyen
> pour modifier l'environnement d'un processus qui est déjà en train de
> tourner (par une méthode "externe" au processus en question, bien
> sûr) ? Genre "hack-env <pid> PATH /the/new/path/:/in/place/of/the/old/
> one" ?




[...]

L'environnement est une liste de strings passées lors de
l'execve() tout comme argv[].

--
Stéphane
Rémi Moyen
Le #16532251
On Aug 12, 3:16 pm, Stephane CHAZELAS wrote:
2008-08-12, 02:36(-07), Rémi Moyen:
[...]> J'ai pas trouvé (en fait, c'est ce que j'avais cherché avant m ême de
> poser ma question), tout ce que j'ai vu c'est comment changer des
> variables avant de lancer KDE, pas une fois qu'il est lancé. Mais je
> trouve les docs de KDE assez inutiles et style "vous êtes dans un
> hélicoptère"... Je vais continuer à chercher et je poserais la
> question (ailleurs, ça n'a pas vraiment sa place ici) si je ne trouve
> pas.

[...]

Tu peux regarder du coté de kshell/kwrapper(1) et creuser a
partir de la.



J'avais vu que tu mentionnais ça dans ton autre message. J'ai un peu
regardé (pas trop le temps, là...), mais je n'arrive pas à trouver
suffisamment de détails pour vraiment comprendre comment je pourrais
utiliser/modifier ça. Je vais encore creuser un peu.

>> > De manière plus globale et par curiosité, est-ce qu'il existe un moyen
>> > pour modifier l'environnement d'un processus qui est déjà en tra in de
>> > tourner (par une méthode "externe" au processus en question, bien
>> > sûr) ? Genre "hack-env <pid> PATH /the/new/path/:/in/place/of/the/ old/
>> > one" ?

[...]

L'environnement est une liste de strings passées lors de
l'execve() tout comme argv[].



Oui, mais l'idée que j'avais en posant cette question-là, c'est que
tout processus a un environnement. Par conséquent, comme c'est un truc
standard (sur un système donné), j'imagine qu'il doit être stocké
quelque part dans la pile (ou ailleurs...) à un endroit prévisible
(par le système, au moins, sinon par un processus en particulier). Et
à partir du moment où il est stocké à un endroit prévisible, j'im agine
qu'il doit être possible à un autre processus, complétement différe nt,
d'aller regarder/modifier cet endroit. C'est ce que fait gdb, en fait,
dans l'exemple que tu donnes !

Bon, maintenant, je suis conscient que 1) c'est une manipulation sans
doute rarement vraiment utile à faire, 2) c'est certainement loin
d'être sans risques (je suppose qu'on doit pouvoir très vite faire des
choses très sales en modifiant l'environnement d'un processus sous ses
pieds pendant qu'il tourne !) et 3) ça demande quand même qu'un
processus aille mettre le nez dans la mémoire allouée à un autre
processus, ce qui est sans doute pas une très bonne idée (sauf le cas
spécial d'un débuggueur).

Pour toutes ces raisons et probablement d'autres que je ne connais
pas, je comprends fort bien qu'on me dise que ça n'est pas faisable
facilement. Mais là, je posais la question plus par curiosité (et
parce que ça me donne l'occasion d'en apprendre un peu plus sur le
fonctionnement de mon système !) que par besoin. Mon besoin (et
encore, c'est plus du confort qu'autre chose), il est du côté de KDE,
peut-être bien kwrapper/kshell.
--
Rémi Moyen
Stephane CHAZELAS
Le #16532531
2008-08-12, 08:34(-07), Rémi Moyen:
[...]
Oui, mais l'idée que j'avais en posant cette question-là, c'est que
tout processus a un environnement.



Tout process a recu un environnement lors du execve(2)
exactement de la meme facon qu'il a recu une liste d'arguments.

Par conséquent, comme c'est un truc
standard (sur un système donné), j'imagine qu'il doit être stocké
quelque part dans la pile (ou ailleurs...) à un endroit prévisible
(par le système, au moins, sinon par un processus en particulier). Et
à partir du moment où il est stocké à un endroit prévisible, j'imagine
qu'il doit être possible à un autre processus, complétement différent,
d'aller regarder/modifier cet endroit.



Sur la plupart des systemes, envp est read-only tout comme argv.

C'est ce que fait gdb, en fait,
dans l'exemple que tu donnes !



Non, gdb faisait appel a putenv, qui va modifier la variable
environ maintenue par la libc. la libc initialise environ avec
ce qui vient de envp. Les variables modifiees et les nouvelles,
ansi que la liste de variables sont mallocée je pense. Cet
environ est utilisé pour les prochains execve(2) que si le
programme utilise des exec{l,v}[p](3), system(3) ou popen(3).

Si le programme ne les utilise pas, ou n'utilise pas la libc,
modifier cet environ n'aura aucun effet. Et il ne peux etre
modifié que par un debugger.

Un programme peut tres bien maintenir internallement la liste
des variables qu'il passera au prochains execve() sans passer
par la libc et ces putenv, setenv et environ. C'est typiquement
le cas des shells.

Bon, maintenant, je suis conscient que 1) c'est une manipulation sans
doute rarement vraiment utile à faire, 2) c'est certainement loin
d'être sans risques (je suppose qu'on doit pouvoir très vite faire des
choses très sales en modifiant l'environnement d'un processus sous ses
pieds pendant qu'il tourne !) et 3) ça demande quand même qu'un
processus aille mettre le nez dans la mémoire allouée à un autre
processus, ce qui est sans doute pas une très bonne idée (sauf le cas
spécial d'un débuggueur).



Exactement.

--
Stéphane
Publicité
Poster une réponse
Anonyme