Comment définir une variable d'environnement pour une session GNOME?

15

Sur mon système, pour les applications qui utilisent SDL, je dois définir une variable d'environnement:

export SDL_AUDIODRIVER=alsa

pour que le son fonctionne correctement. Comment configurer ma session GNOME pour que cette variable soit présente pour toutes les applications (donc si j'exécute une application via Nautilus ou utilise DBGL , les applications fonctionnent correctement)?

ÉDITER:

Fichiers de configuration que j'ai définis (et réinitialisé ma machine après chacun) en vain:

.xsession
.xsessionrc
.gnomerc
.bash_profile
.profile<- Cela fonctionne dans le cas général, mais pas lorsque votre distribution définit la variable ailleurs.
/etc/profile

— Bernard
source

Êtes-vous sûr que cela doit être une variable d'environnement? Il semble que ce pourrait être un autre type de paramètre. Avez-vous fouillé dans l'applet des paramètres sonores du système?

— codeLes

C'est effectivement le cas. C'est ainsi que SDL détermine le backend à utiliser. Je souhaite qu'il utilise simplement un fichier de configuration, mais SDL est assez cohérent dans son utilisation des variables environnementales pour dicter le comportement.

— Bernard

avez-vous vu ceci: modarchive.org/forums/index.php?topic=1879.0

— codeLes

1

Eh bien oui, c'est un choix entre recompiler SDL ou définir une variable d'environnement. Je pense que je fais le bon choix. : p Cela fonctionne (c'est-à-dire, dans un shell, cela fonctionne), c'est juste le problème épineux d'obtenir que GNOME propage la variable pour les applications non démarrées à partir d'un shell qui est le problème. Merci pour votre aide continue.

— Bernard

Dans quelle distribution est-ce?! (Je suis d'accord que la configuration de gdm est vraiment difficile à suivre, donc ma première pensée, "il suffit de regarder dans / etc / gdm / et de lire les scripts" est très pénible.) Ici, .profile semble fonctionner très bien. (debian / testing)

— Anders Eurenius

6

Il se peut que la variable SDL_AUDIODRIVER soit en cours de suppression quelque part. Une stratégie que j'utilise pour les problèmes liés aux scripts de démarrage est de mettre dans les instructions d'écho de débogage qui est simple à activer / désactiver en créant / supprimant un fichier. Vous pouvez commencer par ajouter

debug_msg() {
        test -f $HOME/.debug && echo "$@" 1>&2
}

debug_msg "running ~/.bashrc ($0), SDL_AUDIODRIVER = '$SDL_AUDIODRIVER'"

dans .bashrc, .bash_profile, .profile et / etc / profile pour voir quelle valeur il a et si / où il change.

— hlovdal
source

Mmm, c'est aussi mes pensées actuelles. Il est réglé sur 'pulse', et cela doit être défini quelque part par OpenSUSE. Je ferai du travail de détective quand je rentrerai.

— Bernard

6

https://help.ubuntu.com/community/EnvironmentVariables parle de quatre endroits où nous pouvons définir les variables d'environnement:

~/.pam_environment- […] Ce n'est pas un fichier de script, mais plutôt des expressions d'affectation, une par ligne. […] Nécessite une reconnexion pour initialiser les variables. […]

~/.profile - C'est probablement le meilleur fichier pour placer les affectations de variables d'environnement, car il est exécuté automatiquement par le DisplayManager pendant la session de bureau du processus de démarrage ainsi que par le shell de connexion lorsque l'on se connecte à partir de la console textuelle.

~/.bash_profileou ~/.bash_login- Si l'un de ces fichiers existe, bash l'exécute plutôt que "~ / .profile" lorsqu'il est lancé en tant que shell de connexion. (Bash préférera "~ / .bash_profile" à "~ / .bash_login"). Cependant, ces fichiers n'influenceront pas une session graphique par défaut.

~/.bashrc- En raison de la façon dont Ubuntu configure actuellement les différents fichiers de script par défaut, cela peut être l'endroit le plus simple pour définir des variables. La configuration par défaut garantit presque que ce fichier sera exécuté à chaque invocation de bash ainsi que lors de la journalisation dans l'environnement graphique. Cependant, en termes de performances, ce n'est peut-être pas la meilleure chose à faire car cela entraînera des valeurs inutilement définies plusieurs fois.

http://userbase.kde.org/Session_Environment_Variables/en suggère cet endroit pour KDE:

KDE exécutera tout script qu'il trouve dans $HOME/.kde/envle nom de fichier se terminant par .sh, et il conservera toutes les variables d'environnement définies par eux. Il est important que toute variable que vous souhaitez définir doit également être exportée.

https://help.ubuntu.com/community/ComposeKey#XIM suggère de modifier ~/.gnomercou ~/.Xsession.

— Denilson Sá Maia
source

1

Créez un .gnomercfichier dans votre $ HOME qui est un script shell ( comme.bashrc ) qui définit toutes les variables que vous souhaitez.

— Mike McQuaid
source

Cela ne fonctionne pas pour moi, malheureusement.

— Bernard

Avez-vous essayé d'ouvrir gnome-terminal et confirmé qu'il n'apparaît pas dans env?

— Mike McQuaid

1

@Mike: il est dans mon .bashrc donc il apparaîtra, mais ce serait inexact. Emacs et M-x getenvconfirme qu'il n'est pas remplacé pour les applications GUI.

— Bernard

0

Avez-vous essayé de créer la variable d'environnement int .profile ou / etc / profile ?

Cela devrait fonctionner et devrait déjà exister. Contrairement à .bashrc qui est par session de terminal, ceux-ci sont lancés lors de la connexion à votre session.

— codeLes
source

Hélas, aucun effet.

— Bernard