Pourquoi dois-je 'source .profile` dans chaque terminal que j'ouvre?
Lorsque nous modifions une variable dans ~/.profile dans Ubuntu, nous exécutons la commande source .profile. Ensuite, le changement est effectif niquement dans ce terminal. Si nous ouvrons un nouveau terminal, nous devons exécuter la commande source .profile à nouveau. Il semble donc que différents terminaux ont leur propre environnement, même s’ils peuvent appartenir au même utilisateur.
Quel est l’avantage de faire en sorte que chaque terminal ait son propre chemin d’environnement? Il semble qu'il serait préférable que différents terminaux appartenant au même utilisateur partagent la même variable d'environnement.
La raison en est que ~/.profile est uniquement généré par des shells de connexion. Lorsque vous ouvrez une nouvelle fenêtre de terminal, le shell qui démarre est un shell sans connexion par défaut. Si vous vous déconnectez et que vous vous reconnectez, la modification de ~/.profile sera effective sur tous vos terminaux, car ~/.profile est généré lorsque vous vous connectez à votre session.
Ce n'est pas le cas si différentes fenêtres de terminaux ont un environnement différent, mais le sourcing ~/.profile n'exécute que ~/.profile dans le Shell actuel (c'est exactement ce que fait la commande sourcename__).
En revanche, une modification de ~/.bashrc affectera immédiatement toute nouvelle fenêtre de terminal que vous ouvrez ou tout shell Bash que vous commencez par taper bashname__, car il provient de tous les shells Bash interactifs.
Les variables d'environnement ne sont pas uniquement destinées aux préférences de l'utilisateur. Il s’agit d’un mécanisme générique permettant de communiquer diverses informations de configuration d’un processus parent aux processus enfants qu’il commence.
Il existe de nombreux cas dans lesquels un processus définit des variables d'environnement spécifiques afin d'influencer seulement les processus qu'il démarre. Par exemple, un script peut délibérément réinitialiser les paramètres régionaux pour les commandes qu'il démarre, de sorte qu'il puisse analyser la sortie. Les scripts de génération de nombreux packages logiciels utilisent des appels imbriqués de makequi se coordonnent via des variables d’environnement. Des outils spécialisés peuvent avoir besoin de changer les conditions de travail d’autres programmes, en commençant par des astuces avec $ LD_PRELOAD ou $ PATH.
Si quelque chose qu'un utilisateur fait dans une fenêtre différente alors qu'une longue compilation est en cours d'exécution dans une autre, cela changerait comme par magie les variables d'environnement de tous ses processus derrière son dos, il en résulterait de la folie et du chaos.
D'autres variables d'environnement contiennent des informations sur la session particulière dans laquelle un processus est démarré. Les programmes s'attendent à ce que $ TERM décrive le jeu de commandes du terminal (ou de l'émulateur de terminal) auquel ils sont connectés; en faisant cela, un réglage général par utilisateur rendrait impossible la connexion au même système avec plusieurs types de terminaux. Même si vous ne possédez qu'un seul composant de terminal et ne vous connectez jamais à distance, des programmes tels que screendépendent de la définition d'un $ TERM différent pour les processus exécutés dans leur session.
Une meilleure question serait: pourquoi utilisons-nous un mécanisme de communication de processus à sous-processus pour les paramètres de préférence utilisateur plutôt qu'une base de données par utilisateur?
Réponse: Parce que cela fonctionne assez bien et que les avantages de la création d’une base de données par utilisateur ne sont pas assez importants pour que le travail de modification de tout d'utiliser le fait que au lieu de variables d'environnement serait fait.
(Je peux penser à très peu de paramètres de préférence où ne serait pas des cas d'utilisation où il est pratique de les modifier uniquement pour l'exécution d'un seul script, par exemple. Ainsi, afin de ne pas perdre de fonctionnalité, tout doit toujours être remplaçable par des variables d’environnement, ce qui entraîne une complexité accrue et une confusion accrue des utilisateurs).
Ce n'est pas comme si les alternatives n'existaient pas . Par exemple, les ressources X sont par session d'affichage plutôt que par processus. Mais ils sont difficiles d'accès pour les programmes en ligne de commande - et les programmes en ligne de commande doivent généralement fonctionner pour les connexions distantes qui n'ont même pas un Serveur X auquel se connecter.