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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
> 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, 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.
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.
> 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, 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.
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.
> 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, 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.
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.
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 ?
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 ?
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 ?
J'avais interprété ca comme "gdm lance un shell de login
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.
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" ?
J'avais interprété ca comme "gdm lance un shell de login
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.
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" ?
J'avais interprété ca comme "gdm lance un shell de login
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.
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" ?
> 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.
> 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 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.
> 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.
> 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 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.
> 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.
> 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 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.
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 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" ?
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 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" ?
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 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" ?
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 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[].
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 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[].
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 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'imagine
qu'il doit être possible à un autre processus, complétement différent,
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).
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'imagine
qu'il doit être possible à un autre processus, complétement différent,
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).
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'imagine
qu'il doit être possible à un autre processus, complétement différent,
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).