var denvironnement et xterm/X11

Vincent Lefevre

19/12/2005 à 13:49

Dans l'article <1h7t8n2.uzeifcwl4zcwN%,
Une bévue écrit:

y a t'il un fichier spécifique permettant d'éditer des variables
d'environnement pour le xterm de X11, bien sûr, variables
différentes du terminal/macosx ???

Il me semble que tu cherches plutôt à modifier les variables
d'environnement de ton shell. Pour zsh, c'est dans le ".zshenv".
Pour bash, il faut modifier à la fois le .bashrc et le .bash_profile
(mais tu peux avoir un fichier commun pour cela et utiliser le
builtin "source").

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

pere.noel

19/12/2005 à 14:00

Vincent Lefevre <vincent+ wrote:

Il me semble que tu cherches plutôt à modifier les variables
d'environnement de ton shell. Pour zsh, c'est dans le ".zshenv".
Pour bash, il faut modifier à la fois le .bashrc et le .bash_profile
(mais tu peux avoir un fichier commun pour cela et utiliser le
builtin "source").

ah oui, mais justement je ne veux pas que la config soit commune entre
mon shell zsh MacOS X et le shell xterm bash X11.

j'ai donc édité un ~/.bash_profile :
export
PATH=/Users/yvon/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/User
s/yvon/bin/maven/bin:/Users/yvon/bin/groovy/bin:/opt/local/bin:/sw/bin:/
sw/sbin:.:/bin:/usr/bin:/sbin:/usr/sbin:/usr/X$
export ACLOCAL_FLAGS="-I /opt/local/share/glade-2"
export PKG_CONFIG_PATH=/usr/lib/pkgconfig
export RUBYOPT=rubygems

mais quand je lance X11 et son xterm j'ai bien $ACLOCAL_FLAGS,
$PKG_CONFIG_PATH, $RUBYOPT

MAIS << le $PATH ne contient pas certaines choses notamment
"/Users/yvon/bin"

et bien sûr, je ne pige pas pourquoi...
--
une bévue

Vincent Lefevre

19/12/2005 à 15:34

Dans l'article <1h7tldg.k7b0fx84amgwN%,
Une bévue écrit:

Vincent Lefevre <vincent+ wrote:

Il me semble que tu cherches plutôt à modifier les variables
d'environnement de ton shell. Pour zsh, c'est dans le ".zshenv".
Pour bash, il faut modifier à la fois le .bashrc et le .bash_profile
(mais tu peux avoir un fichier commun pour cela et utiliser le
builtin "source").

ah oui, mais justement je ne veux pas que la config soit commune entre
mon shell zsh MacOS X et le shell xterm bash X11.

Quand je parlais de fichier commun, c'était pour bash, car bash
utilise soit .bashrc, soit .bash_profile suivant la façon dont
bash est lancé. Je préfère la méthode de zsh, qui est de sourcer
toujours .zshenv, et ne sourcer .zshrc que si le shell est
interactif (et .zlogin en 3e dans le cas d'un shell de login);
tout est indiqué dans le manuel.

En fait, j'ai dans mon .bash_profile:

[[ -f ~/.bashrc ]] && source ~/.bashrc

ce qui permet d'émuler la méthode de zsh au niveau des shells bash
interactifs.

j'ai donc édité un ~/.bash_profile :
export
PATH=/Users/yvon/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/User
s/yvon/bin/maven/bin:/Users/yvon/bin/groovy/bin:/opt/local/bin:/sw/bin:/
sw/sbin:.:/bin:/usr/bin:/sbin:/usr/sbin:/usr/X$
export ACLOCAL_FLAGS="-I /opt/local/share/glade-2"
export PKG_CONFIG_PATH=/usr/lib/pkgconfig
export RUBYOPT=rubygems

mais quand je lance X11 et son xterm j'ai bien $ACLOCAL_FLAGS,
$PKG_CONFIG_PATH, $RUBYOPT

Le .bash_profile n'est exécuté que dans le cas d'un shell de login,
à voir si c'est ton cas (je ne pense pas). Attention, les variables
d'environnement sont exportées aux processus fils, donc la valeur de
ACLOCAL_FLAGS, etc. peut provenir d'un shell bash de login parent.

MAIS << le $PATH ne contient pas certaines choses notamment
"/Users/yvon/bin"

et bien sûr, je ne pige pas pourquoi...

Si tu as le X11 d'Apple, il semble redéfinir l'environnement (de
manière partielle). Ainsi j'avais créé un .xinitrc et essayé de
fixer certaines choses dedans (XAPPLRESDIR si je me souviens bien),
mais les valeurs de certaines variables étaient changées dans les
xterm lancées depuis le menu X11.

Bref, je pense que ton problème est le suivant:
1. Certaines variables d'environnement (PATH, ACLOCAL_FLAGS, etc.)
sont définies dans ton shell de login.
2. Quand tu lances le serveur X11 (qui reprend éventuellement
l'environnement du shell de login -- je ne sais pas bien
ce qui se passe sous Mac OS X, je suis plutôt habitué aux
autres Unix avec login en mode texte et lancement d'une
session X11 à la main), certaines variables sont redéfinies
(au niveau du serveur).
3. Quand tu lances ton xterm depuis X11, il récupère évidemment
l'environnement (modifié) du serveur.
4. Ensuite xterm lance un shell bash interactif, mais qui n'est
pas un shell de login (c'est logique, mais tu peux décider
autrement avec une commande du style "xterm -e bash -l"),
donc seul le .bashrc est sourcé.

Je te conseille de mettre tes variables d'environnement dans ton
.bashrc et, si tu en as envie, de faire comme je fais:

[[ -f ~/.bashrc ]] && source ~/.bashrc

au début du .bash_profile (le reste du .bash_profile contenant des
trucs qui ne servent qu'au login). En effet, je ne vois pas pourquoi
un shell de login ne devrait pas avoir l'environnement utilisé pour
les autres shells interactifs.

Et dans ton .bashrc, faire ceci:

# If running interactively, then:
if [ "$PS1" ]; then
[... des trucs qui ne servent qu'aux shells interactifs ...]
fi

Note: théoriquement, la définition des variables d'environnement
ne devrait être utile que dans un shell de login puisque tout est
exporté aux processus fils. Mais comme on peut le voir, certaines
applications redéfinissent des variables d'environnement, donc je
dirais que ces variables doivent en pratique systématiquement être
définies au lancement de tout shell (c'est la politique de zsh).

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Dans l'article <1h7tldg.k7b0fx84amgwN%pere.noel@laponie.com>,
Une bévue <pere.noel@laponie.com> écrit:

Vincent Lefevre <vincent+news@vinc17.org> wrote:

Il me semble que tu cherches plutôt à modifier les variables
d'environnement de ton shell. Pour zsh, c'est dans le ".zshenv".
Pour bash, il faut modifier à la fois le .bashrc et le .bash_profile
(mais tu peux avoir un fichier commun pour cela et utiliser le
builtin "source").

ah oui, mais justement je ne veux pas que la config soit commune entre
mon shell zsh MacOS X et le shell xterm bash X11.

Quand je parlais de fichier commun, c'était pour bash, car bash
utilise soit .bashrc, soit .bash_profile suivant la façon dont
bash est lancé. Je préfère la méthode de zsh, qui est de sourcer
toujours .zshenv, et ne sourcer .zshrc que si le shell est
interactif (et .zlogin en 3e dans le cas d'un shell de login);
tout est indiqué dans le manuel.

En fait, j'ai dans mon .bash_profile:

[[ -f ~/.bashrc ]] && source ~/.bashrc

ce qui permet d'émuler la méthode de zsh au niveau des shells bash
interactifs.

j'ai donc édité un ~/.bash_profile :
export
PATH=/Users/yvon/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/User
s/yvon/bin/maven/bin:/Users/yvon/bin/groovy/bin:/opt/local/bin:/sw/bin:/
sw/sbin:.:/bin:/usr/bin:/sbin:/usr/sbin:/usr/X$
export ACLOCAL_FLAGS="-I /opt/local/share/glade-2"
export PKG_CONFIG_PATH=/usr/lib/pkgconfig
export RUBYOPT=rubygems

mais quand je lance X11 et son xterm j'ai bien $ACLOCAL_FLAGS,
$PKG_CONFIG_PATH, $RUBYOPT

Le .bash_profile n'est exécuté que dans le cas d'un shell de login,
à voir si c'est ton cas (je ne pense pas). Attention, les variables
d'environnement sont exportées aux processus fils, donc la valeur de
ACLOCAL_FLAGS, etc. peut provenir d'un shell bash de login parent.

MAIS << le $PATH ne contient pas certaines choses notamment
"/Users/yvon/bin"

et bien sûr, je ne pige pas pourquoi...

Si tu as le X11 d'Apple, il semble redéfinir l'environnement (de
manière partielle). Ainsi j'avais créé un .xinitrc et essayé de
fixer certaines choses dedans (XAPPLRESDIR si je me souviens bien),
mais les valeurs de certaines variables étaient changées dans les
xterm lancées depuis le menu X11.

Bref, je pense que ton problème est le suivant:
1. Certaines variables d'environnement (PATH, ACLOCAL_FLAGS, etc.)
sont définies dans ton shell de login.
2. Quand tu lances le serveur X11 (qui reprend éventuellement
l'environnement du shell de login -- je ne sais pas bien
ce qui se passe sous Mac OS X, je suis plutôt habitué aux
autres Unix avec login en mode texte et lancement d'une
session X11 à la main), certaines variables sont redéfinies
(au niveau du serveur).
3. Quand tu lances ton xterm depuis X11, il récupère évidemment
l'environnement (modifié) du serveur.
4. Ensuite xterm lance un shell bash interactif, mais qui n'est
pas un shell de login (c'est logique, mais tu peux décider
autrement avec une commande du style "xterm -e bash -l"),
donc seul le .bashrc est sourcé.

Je te conseille de mettre tes variables d'environnement dans ton
.bashrc et, si tu en as envie, de faire comme je fais:

[[ -f ~/.bashrc ]] && source ~/.bashrc

au début du .bash_profile (le reste du .bash_profile contenant des
trucs qui ne servent qu'au login). En effet, je ne vois pas pourquoi
un shell de login ne devrait pas avoir l'environnement utilisé pour
les autres shells interactifs.

Et dans ton .bashrc, faire ceci:

# If running interactively, then:
if [ "$PS1" ]; then
[... des trucs qui ne servent qu'aux shells interactifs ...]
fi

Note: théoriquement, la définition des variables d'environnement
ne devrait être utile que dans un shell de login puisque tout est
exporté aux processus fils. Mais comme on peut le voir, certaines
applications redéfinissent des variables d'environnement, donc je
dirais que ces variables doivent en pratique systématiquement être
définies au lancement de tout shell (c'est la politique de zsh).

--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Vous avez filtré cet utilisateur ! Consultez son message

Dans l'article <1h7tldg.k7b0fx84amgwN%,
Une bévue écrit:

Vincent Lefevre <vincent+ wrote:

Il me semble que tu cherches plutôt à modifier les variables
d'environnement de ton shell. Pour zsh, c'est dans le ".zshenv".
Pour bash, il faut modifier à la fois le .bashrc et le .bash_profile
(mais tu peux avoir un fichier commun pour cela et utiliser le
builtin "source").

ah oui, mais justement je ne veux pas que la config soit commune entre
mon shell zsh MacOS X et le shell xterm bash X11.

Quand je parlais de fichier commun, c'était pour bash, car bash
utilise soit .bashrc, soit .bash_profile suivant la façon dont
bash est lancé. Je préfère la méthode de zsh, qui est de sourcer
toujours .zshenv, et ne sourcer .zshrc que si le shell est
interactif (et .zlogin en 3e dans le cas d'un shell de login);
tout est indiqué dans le manuel.

En fait, j'ai dans mon .bash_profile:

[[ -f ~/.bashrc ]] && source ~/.bashrc

ce qui permet d'émuler la méthode de zsh au niveau des shells bash
interactifs.

j'ai donc édité un ~/.bash_profile :
export
PATH=/Users/yvon/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/User
s/yvon/bin/maven/bin:/Users/yvon/bin/groovy/bin:/opt/local/bin:/sw/bin:/
sw/sbin:.:/bin:/usr/bin:/sbin:/usr/sbin:/usr/X$
export ACLOCAL_FLAGS="-I /opt/local/share/glade-2"
export PKG_CONFIG_PATH=/usr/lib/pkgconfig
export RUBYOPT=rubygems

mais quand je lance X11 et son xterm j'ai bien $ACLOCAL_FLAGS,
$PKG_CONFIG_PATH, $RUBYOPT

Le .bash_profile n'est exécuté que dans le cas d'un shell de login,
à voir si c'est ton cas (je ne pense pas). Attention, les variables
d'environnement sont exportées aux processus fils, donc la valeur de
ACLOCAL_FLAGS, etc. peut provenir d'un shell bash de login parent.

MAIS << le $PATH ne contient pas certaines choses notamment
"/Users/yvon/bin"

et bien sûr, je ne pige pas pourquoi...

Si tu as le X11 d'Apple, il semble redéfinir l'environnement (de
manière partielle). Ainsi j'avais créé un .xinitrc et essayé de
fixer certaines choses dedans (XAPPLRESDIR si je me souviens bien),
mais les valeurs de certaines variables étaient changées dans les
xterm lancées depuis le menu X11.

Bref, je pense que ton problème est le suivant:
1. Certaines variables d'environnement (PATH, ACLOCAL_FLAGS, etc.)
sont définies dans ton shell de login.
2. Quand tu lances le serveur X11 (qui reprend éventuellement
l'environnement du shell de login -- je ne sais pas bien
ce qui se passe sous Mac OS X, je suis plutôt habitué aux
autres Unix avec login en mode texte et lancement d'une
session X11 à la main), certaines variables sont redéfinies
(au niveau du serveur).
3. Quand tu lances ton xterm depuis X11, il récupère évidemment
l'environnement (modifié) du serveur.
4. Ensuite xterm lance un shell bash interactif, mais qui n'est
pas un shell de login (c'est logique, mais tu peux décider
autrement avec une commande du style "xterm -e bash -l"),
donc seul le .bashrc est sourcé.

Je te conseille de mettre tes variables d'environnement dans ton
.bashrc et, si tu en as envie, de faire comme je fais:

[[ -f ~/.bashrc ]] && source ~/.bashrc

au début du .bash_profile (le reste du .bash_profile contenant des
trucs qui ne servent qu'au login). En effet, je ne vois pas pourquoi
un shell de login ne devrait pas avoir l'environnement utilisé pour
les autres shells interactifs.

Et dans ton .bashrc, faire ceci:

# If running interactively, then:
if [ "$PS1" ]; then
[... des trucs qui ne servent qu'aux shells interactifs ...]
fi

Note: théoriquement, la définition des variables d'environnement
ne devrait être utile que dans un shell de login puisque tout est
exporté aux processus fils. Mais comme on peut le voir, certaines
applications redéfinissent des variables d'environnement, donc je
dirais que ces variables doivent en pratique systématiquement être
définies au lancement de tout shell (c'est la politique de zsh).

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Une bévue

19/12/2005 à 16:23

Le Mon, 19 Dec 2005 14:34:41 +0000, Vincent Lefevre a écrit :

donc je dirais que ces
variables doivent en pratique systématiquement être définies au
lancement de tout shell (c'est la politique de zsh).

évidemment, c'est celle que je préfère, je te r(emercie pour tes
précieux conseils.

mais, un truc m'intrigue tu as l'air de laisser entendre que je pourrais
utiliser aussi zsh comme shell avec X11 (lancer à partir de X11.app).

un solution serait peut-re de lancer X11 par un script depuis le Terminal
usuel ?

--
Une bévue

Vincent Lefevre

19/12/2005 à 17:04

Dans l'article ,
Une bévue écrit:

mais, un truc m'intrigue tu as l'air de laisser entendre que je pourrais
utiliser aussi zsh comme shell avec X11 (lancer à partir de X11.app).

Je ne vois pas ce que tu veux dire. X11 n'est pas un shell (il utilise
des scripts dans un shell ou un autre, mais il ne faut pas modifier
cela). Ensuite, tu peux lancer des terminaux à partir du menu ou à
partir d'un shell (ou de toute autre façon...). Pour xterm, le shell
lancé par le terminal est $SHELL si cette variable d'environnement est
définie, sinon le shell spécifié par le compte de l'utilisateur (e.g.
dans /etc/passwd); je ne sais pas s'il en est de même pour tous les
terminaux.

En ce qui me concerne, j'ai un "exec zsh -l" à la fin de mon
.bash_profile, et je n'ai pas eu de problème avec. Note: je dois
lancer un shell de login ici, car il est fort possible que le zsh
lancé ici soit le premier zsh qui tourne sur la machine, et j'ai
besoin de mettre en place certaines choses dans ce cas.

un solution serait peut-re de lancer X11 par un script depuis le
Terminal usuel ?

Quel intérêt?

Note: quand j'avais parlé de l'environnement du serveur C, ce n'était
pas tout à fait correct. Je voulais parler de l'environnement du
window manager (quartz-wm dans mon cas); c'est cet environnement
qui est pris en compte quand on lance des applications X à partir
de la barre de menu X11. Un ps arborescent donne chez moi:

16838 /Applications/Utilities/X11.app/Contents/MacOS/X11 -psn_0_2136473
+-> 16839 /Applications/Utilities/X11.app/Contents/MacOS/X11 -nolisten
`-> 16840 quartz-wm
`-> 16845 (xterm)

En gros, je soupçonne quartz-wm de poser ces problèmes d'environnement.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Vincent Lefevre

19/12/2005 à 17:08

Dans l'article ,
Une bévue écrit:

mais, un truc m'intrigue tu as l'air de laisser entendre que je pourrais
utiliser aussi zsh comme shell avec X11 (lancer à partir de X11.app).

Je ne vois pas ce que tu veux dire. X11 n'est pas un shell (il utilise
des scripts dans un shell ou un autre, mais il ne faut pas modifier
cela). Ensuite, tu peux lancer des terminaux à partir du menu ou à
partir d'un shell (ou de toute autre façon...). Pour xterm, le shell
lancé par le terminal est $SHELL si cette variable d'environnement est
définie, sinon le shell spécifié par le compte de l'utilisateur (e.g.
dans /etc/passwd); je ne sais pas s'il en est de même pour tous les
terminaux.

En ce qui me concerne, j'ai un "exec zsh -l" à la fin de mon
.bash_profile, et je n'ai pas eu de problème avec. Note: je dois
lancer un shell de login ici, car il est fort possible que le zsh
lancé ici soit le premier zsh qui tourne sur la machine, et j'ai
besoin de mettre en place certaines choses dans ce cas.

un solution serait peut-re de lancer X11 par un script depuis le
Terminal usuel ?

Quel intérêt?

Note: quand j'avais parlé de l'environnement du serveur X, ce n'était
pas tout à fait correct. Je voulais parler de l'environnement du
window manager (quartz-wm dans mon cas); c'est cet environnement
qui est pris en compte quand on lance des applications X à partir
de la barre de menu X11. Un ps arborescent donne chez moi:

16838 /Applications/Utilities/X11.app/Contents/MacOS/X11 -psn_0_2136473
+-> 16839 /Applications/Utilities/X11.app/Contents/MacOS/X11 -nolisten
`-> 16840 quartz-wm
`-> 16845 (xterm)

En gros, je soupçonne quartz-wm de poser ces problèmes d'environnement.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Une bévue

19/12/2005 à 17:40

Le Mon, 19 Dec 2005 16:59:18 +0100, Matt a écrit :

Si dans la babase NI, ton shell de connexion est zsh, alors xterm
utilisera ce shell (sauf bien sûr si tu as fait des bidouilles merdiques
dans un .xinitrc, ce que je crois dur comme fer).

ben non je n'ai pas de .xinitrc dans ~/ le shell dans xterm
est bash et dans le terminal c'est zsh...

je n'ai pas touché à NI, j'ai juste ajouté, un rép de config pour zsh :

~/Library/init/

en fait j'ai suivi une procédure d'installation de joyce sur mosx.net.

dans le Terminal c'est assez facile de changer de shell (préférences)
car pour je ne sais plus trop quoi (je suis sous linux en ce moment) il
faut utiliser bash alors que j'utilise par défaut zsh.

bon, je vais revoir tout ça pour n'utiliser que zsh, par défaut, xterm
comme terminal, donc jetter un oeil sur NI.

--
Une bévue

Une bévue

19/12/2005 à 23:12

Le Mon, 19 Dec 2005 20:15:38 +0100, Matt a écrit :

Zsh ne pose pas de problèmes particuliers sur Mac OS X.
non mais dans un readme d'install d'un soft il était dit que le shell

devait être bash, je n'avais jamais rencontré ce requirement ))

--
Une bévue

Vincent Lefevre

20/12/2005 à 02:23

Dans l'article ,
Une bévue écrit:

Le Mon, 19 Dec 2005 20:15:38 +0100, Matt a écrit :

Zsh ne pose pas de problèmes particuliers sur Mac OS X.
non mais dans un readme d'install d'un soft il était dit que le shell

devait être bash, je n'avais jamais rencontré ce requirement ))

Ils voulaient peut-être dire que le /bin/sh devait être bash (ou
compatible, et zsh l'est), ce qui est le cas sous Linux et sous
Mac OS X (Tiger au moins). De toute façon, les scripts commencent
par une ligne indiquant le shell, donc le fait que tu utilises zsh
ne doit pas poser de problème.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

var denvironnement et xterm/X11

9 réponses

Veuillez sélectionner un problème