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 démarre.
Il existe de nombreux cas où un processus définira des variables d'environnement spécifiques afin d'influencer uniquement les processus qu'il démarre. Par exemple, un script peut délibérément réinitialiser les paramètres régionaux des commandes qu'il démarre, de sorte qu'il peut analyser la sortie d'eux. Les scripts de construction de nombreux logiciels volumineux utilisent des invocations imbriquées de make
ces coordonnées entre elles via des variables d'environnement. Les outils spécialisés peuvent avoir besoin de changer les conditions de travail des autres programmes qu'ils démarrent en faisant des tours avec $ LD_PRELOAD ou $ PATH.
Si quelque chose qu'un utilisateur fait dans une fenêtre différente pendant qu'une longue compilation s'exécute dans une autre change simplement comme par magie les variables d'environnement de tous ses processus derrière leur dos, la folie et le chaos en résulteraient.
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 l'ensemble de commandes du terminal particulier (ou de l'émulateur de terminal) auquel ils sont connectés; en faisant cela, un paramètre général par utilisateur rendrait impossible la connexion au même système avec plusieurs types de terminaux différents. Même si vous ne disposez que d'un seul matériel terminal et que vous ne vous connectez jamais à distance, des programmes tels que screen
dépendent de la définition d'un $ TERM différent pour les processus qui s'exécutent à l'intérieur de 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 créer une base de données par utilisateur ne sont pas suffisamment importants pour que le travail de tout changer pour l'utiliser plutôt que les variables d'environnement soit effectué.
(Je peux penser à très peu de paramètres de préférence où il n'y aurait pas de cas d'utilisation où il serait pratique de les changer juste pour exécuter un seul script, par exemple. Donc, pour ne pas perdre de fonctionnalité, tout devrait encore être remplaçable par variables d’environnement, ce qui entraîne une complexité accrue et des utilisateurs plus confus).
Il est pas comme si des solutions de rechange n'existent . 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 de ligne de commande - et les programmes de ligne de commande ont généralement besoin de travailler pour les connexions à distance qui ne même pas ont un serveur X pour se connecter.