Le 12 September 2005 à 08:09, Jean-Michel Caricand vraute :
Je travaille sur un projet en C++. J'ai défini 2 variables que j'exporte depuis .bashrc.
Lorsque je compile à la ligne de commande tout va bien. Depuis Emacs, les deux variables ne sont pas définit. Avez-vous une solution ?
Peut-être un problème d'environnement différent ? Comment lances-tu emacs ? Depuis le même shell que celui où tu définis tes variables ?
Qu'est-ce que tu vois si tu fais un M-: (getenv "TA_VARIABLE_SANS_$") ?
Une autre question concerne l'utilisation de polices truetype dans Emacs. Comment utiliser ce type de polices dans les fenêtres d'édition ?
Une solution a été apporté dans gnu.emacs.help à ce sujet : <news:
Peut-être que ça t'aidera aussi ? -- Sébastien Kirche
lhabert
Jean-Michel Caricand :
Je travaille sur un projet en C++. J'ai défini 2 variables que j'exporte depuis .bashrc.
Lorsque je compile à la ligne de commande tout va bien. Depuis Emacs, les deux variables ne sont pas définit. Avez-vous une solution ?
Chaque processus a son propre jeu de variables d'environnement. En général, il hérite une copie de celui son père, et qu'il peut ensuite modifier. Donc avec les définitions que tu as faites dans ton .bashrc, tu agis sur l'environnement de tous les progammes que tu lances avec un bash interactif. Si tu lances ton emacs par une autre branche de l'arbre des process de la session, tu ne les as pas.
La solution consiste à effectuer ces définitions d'environnement dans le processus qui enfante toute ta session. La méthode à employer diffère selon la manière dont tu te logues. - si tu te logues en console (et lance X par startx) ou à distance, alors tu as un shell de login de lancé, et il faut agir sur le fichier exécuté par ton shell de login (pour bash, c'est le .bash_profile) - si tu as un login graphique, il faut t'arranger pour qu'il exécute un script à toi. Avec un peu de chance, en te créant un script « .xsession » (cf plus bas), et en choisissant le bon type de session dans le xdm/gdm/kdm (souvent « system default » ou un machin du genre, enfin tout sauf « gnome » et « kde »), ça sera bon. Maintenant, quoi mettre dedans? Quelque chose comme ça :
#!/bin/sh
# Tes définitions de variables FOOºr CORGE=grault
export FOO CORGE
# On lance l'environnement graphique, qui va enfanter toute la session. exec startkde # pour lancer KDE. Pour Gnome, mettre « gnome-session » à la # place de « startkde ». Pour autre chose, mettre le nom du # WM.
, et tu rends le script exécutable (« chmod 755 .xsession »). Tu peux ajouter tout ce que tu veux exécuter au début de ta session, à condition de le mettre avant le exec.
En fait, ça peut-être bien de partager ta définition d'environnement entre les différentes manières de se loguer. La solution classique consiste à te créer un fichier « .env » dans lequel tu mets tes définitions de variables, et ensuite, dans ton .bash_profile, tu mets juste :
. ~/.env
(pour lui dire d'include le contenu de ce fichier), et dans ton .xsession :
#!/bin/sh
. ~/.env
exec startkde
. C'est la solution historique. Personellement, je préfère faire ça en CPS. Tu fais un script .init_env contenant
#!/bin/sh
FOOºr # ...
exec "$@"
, et dans le .profile :
#!/bin/sh
exec ~/.init_env "$SHELL"
et dans le .xsession :
#!/bin/sh
exec ~/.init_env startkde
. C'est plus pratique quand on veut initialiser l'environnement en dehors d'une situation de login.
Jean-Michel Caricand :
Je travaille sur un projet en C++. J'ai défini 2 variables que j'exporte
depuis .bashrc.
Lorsque je compile à la ligne de commande tout va bien. Depuis Emacs, les
deux variables ne sont pas définit. Avez-vous une solution ?
Chaque processus a son propre jeu de variables d'environnement. En général,
il hérite une copie de celui son père, et qu'il peut ensuite modifier. Donc
avec les définitions que tu as faites dans ton .bashrc, tu agis sur
l'environnement de tous les progammes que tu lances avec un bash interactif.
Si tu lances ton emacs par une autre branche de l'arbre des process de la
session, tu ne les as pas.
La solution consiste à effectuer ces définitions d'environnement dans le
processus qui enfante toute ta session. La méthode à employer diffère selon
la manière dont tu te logues.
- si tu te logues en console (et lance X par startx) ou à distance, alors tu
as un shell de login de lancé, et il faut agir sur le fichier exécuté par
ton shell de login (pour bash, c'est le .bash_profile)
- si tu as un login graphique, il faut t'arranger pour qu'il exécute un
script à toi. Avec un peu de chance, en te créant un script « .xsession »
(cf plus bas), et en choisissant le bon type de session dans le xdm/gdm/kdm
(souvent « system default » ou un machin du genre, enfin tout sauf « gnome »
et « kde »), ça sera bon. Maintenant, quoi mettre dedans? Quelque chose
comme ça :
#!/bin/sh
# Tes définitions de variables
FOOºr
CORGE=grault
export FOO CORGE
# On lance l'environnement graphique, qui va enfanter toute la session.
exec startkde # pour lancer KDE. Pour Gnome, mettre « gnome-session » à la
# place de « startkde ». Pour autre chose, mettre le nom du
# WM.
, et tu rends le script exécutable (« chmod 755 .xsession »). Tu peux
ajouter tout ce que tu veux exécuter au début de ta session, à condition de
le mettre avant le exec.
En fait, ça peut-être bien de partager ta définition d'environnement entre
les différentes manières de se loguer. La solution classique consiste à te
créer un fichier « .env » dans lequel tu mets tes définitions de variables,
et ensuite, dans ton .bash_profile, tu mets juste :
. ~/.env
(pour lui dire d'include le contenu de ce fichier), et dans ton .xsession :
#!/bin/sh
. ~/.env
exec startkde
. C'est la solution historique. Personellement, je préfère faire ça en CPS.
Tu fais un script .init_env contenant
#!/bin/sh
FOOºr
# ...
exec "$@"
, et dans le .profile :
#!/bin/sh
exec ~/.init_env "$SHELL"
et dans le .xsession :
#!/bin/sh
exec ~/.init_env startkde
. C'est plus pratique quand on veut initialiser l'environnement en dehors
d'une situation de login.
Je travaille sur un projet en C++. J'ai défini 2 variables que j'exporte depuis .bashrc.
Lorsque je compile à la ligne de commande tout va bien. Depuis Emacs, les deux variables ne sont pas définit. Avez-vous une solution ?
Chaque processus a son propre jeu de variables d'environnement. En général, il hérite une copie de celui son père, et qu'il peut ensuite modifier. Donc avec les définitions que tu as faites dans ton .bashrc, tu agis sur l'environnement de tous les progammes que tu lances avec un bash interactif. Si tu lances ton emacs par une autre branche de l'arbre des process de la session, tu ne les as pas.
La solution consiste à effectuer ces définitions d'environnement dans le processus qui enfante toute ta session. La méthode à employer diffère selon la manière dont tu te logues. - si tu te logues en console (et lance X par startx) ou à distance, alors tu as un shell de login de lancé, et il faut agir sur le fichier exécuté par ton shell de login (pour bash, c'est le .bash_profile) - si tu as un login graphique, il faut t'arranger pour qu'il exécute un script à toi. Avec un peu de chance, en te créant un script « .xsession » (cf plus bas), et en choisissant le bon type de session dans le xdm/gdm/kdm (souvent « system default » ou un machin du genre, enfin tout sauf « gnome » et « kde »), ça sera bon. Maintenant, quoi mettre dedans? Quelque chose comme ça :
#!/bin/sh
# Tes définitions de variables FOOºr CORGE=grault
export FOO CORGE
# On lance l'environnement graphique, qui va enfanter toute la session. exec startkde # pour lancer KDE. Pour Gnome, mettre « gnome-session » à la # place de « startkde ». Pour autre chose, mettre le nom du # WM.
, et tu rends le script exécutable (« chmod 755 .xsession »). Tu peux ajouter tout ce que tu veux exécuter au début de ta session, à condition de le mettre avant le exec.
En fait, ça peut-être bien de partager ta définition d'environnement entre les différentes manières de se loguer. La solution classique consiste à te créer un fichier « .env » dans lequel tu mets tes définitions de variables, et ensuite, dans ton .bash_profile, tu mets juste :
. ~/.env
(pour lui dire d'include le contenu de ce fichier), et dans ton .xsession :
#!/bin/sh
. ~/.env
exec startkde
. C'est la solution historique. Personellement, je préfère faire ça en CPS. Tu fais un script .init_env contenant
#!/bin/sh
FOOºr # ...
exec "$@"
, et dans le .profile :
#!/bin/sh
exec ~/.init_env "$SHELL"
et dans le .xsession :
#!/bin/sh
exec ~/.init_env startkde
. C'est plus pratique quand on veut initialiser l'environnement en dehors d'une situation de login.
