Fonds Linux
  1. Fonds Linux
  3. Définir la variable d'environnement pour tous les shells tmux lorsque les sessions gnome sont redémarrées
Intereting Posts
Quels sont les caractères spéciaux à imprimer à partir d'un script pour déplacer le slider? Que signifie "Read Swap Header failed: Success" signifie? Réinitialisation du controller MMC sans retirer physiquement la carte? Quelle est la différence entre les applications GTK et QT? S'échapper correctement de la sortie du tuyau dans xargs assembly du dossier réseau local dans Ubuntu parallèle gnu: arguments et espaces cités dans les noms de files. Comment résoudre? linux: trouve un nom qui a 5 caractères seulement dans un text Modifier datatables en colonnes dans vim Comment réparer une database Banshee malformée? Comment puis-je savoir si mon disque dur est PATA ou SATA? Sous AIX, comment puis-je get le path complet d'un programme lié à un port? Configuration d'Utorrent sous Linux MINT 18 Pourquoi ne puis-je pas appeler ce programme en utilisant son path complet? Comment créer un USB amorçable FreeBSD 10?

Définir la variable d'environnement pour tous les shells tmux lorsque les sessions gnome sont redémarrées

Pour résoudre ce problème , je dois définir la variable d'environnement DBUS_SESSION_BUS_ADDRESS pour tous les shells à l'intérieur de tmux chaque fois que je redémarre gnome sans redémarrer tmux (c'est souvent le cas). Comment puis-je le résoudre le mieux?

  • Je ne peux pas nettoyer proprement l'environnement d'un autre process .
  • Je ne peux pas envoyer une command à chaque volet
  • Je pourrais mettre la variable d'environnement dans mon PROMPT_COMMAND . Cela signifie que je dois appuyer sur Entrée avant de pouvoir exécuter des applications gnome. C'est moche et exagéré.
  • Je pourrais définir la variable d'environnement en exécutant une command avant chaque command , mais c'est un peu exagéré.

Y a-t-il un autre moyen de remédier à ce problème de manière plus propre?

Dans ce cas particulier, au lieu de laisser Gnome exécuter dbus-launch pour créer une adresse D-Bus random, lancez dbus-daemon explicitement au début de votre session X et donnez-lui une adresse fixe comme unix:path=~/.dbus-$HOSTNAME-$DISPLAY .

Compte tenu de l'information contenue dans le rapport de bogue , vous pouvez même vous débarrasser de unset DBUS_SESSION_BUS_ADDRESS et laisser les applications searchr l'adresse de bus à partir des propriétés de la window racine.

Dans le cas général, votre évaluation est correcte: tout ce que vous avez est des methods peu fiables comme ptrace (qui peuvent planter le programme ou ne fonctionnent pas en raison d'un framework de security comme Apparmor ou SELinux) ou en injectant une command shell volets qui sont actuellement à une invite du shell). Exécuter une command à chaque invite du shell (avec le preexec de zsh ou le PROMPT_COMMAND de bash) ne risque pas au less de casser des trucs.

Une autre solution serait une bibliothèque LD_PRELOAD qui intercepte les appels getenv . Cela semble aussi exagéré.

Votre meilleur pari est de laisser l'application faire le travail en créant un niveau d'indirection: faire en sorte que la valeur de la variable d'environnement rest valide et que l'application l'interprète de manière consciente. Laisser l'application searchr l'adresse du bus D-Bus dans les propriétés de la window racine est un exemple de cette approche.