Que font les scripts dans /etc/profile.d?
Je lis sur les scripts Shell de base à partir de Linux Command Line et Shell Scripting Bible .
Il indique que le fichier /etc/profile Définit les variables d'environnement au démarrage du shell Bash. Le répertoire /etc/profile.d Contient d'autres scripts qui contiennent des fichiers de démarrage spécifiques à l'application, qui sont également exécutés au démarrage par le shell.
Pourquoi ces fichiers ne font-ils pas partie de
/etc/profileS'ils sont également essentiels au démarrage de Bash?Si ces fichiers sont des fichiers de démarrage spécifiques à l'application qui ne sont pas essentiels au démarrage de Bash, alors pourquoi font-ils partie du processus de démarrage? Pourquoi ne s'exécutent-ils que lorsque les applications spécifiques, pour lesquelles ils contiennent des paramètres, sont exécutées?
Pourquoi ces fichiers ne font-ils pas partie de/etc/profile s'ils sont également essentiels au démarrage de Bash?
Si vous voulez dire: "Pourquoi ne sont-ils pas simplement combinés en un seul script géant?", La réponse est:
- Parce que ce serait un cauchemar de maintenance pour les personnes responsables des scripts.
- Parce que le fait de charger les scripts en tant que modules indépendants rend l'ensemble du système plus réglable dynamiquement - des scripts individuels peuvent être ajoutés et supprimés sans affecter les autres. Etc.
- Parce qu'ils sont chargés via/etc/profile, ce qui en fait de toute façon une partie du "profil" bash.
Si ces fichiers sont des fichiers de démarrage spécifiques à une application qui ne sont pas essentiels au démarrage de Bash, alors pourquoi font-ils partie du processus de démarrage? Pourquoi ne sont-ils pas exécutés uniquement lorsque les applications spécifiques, pour lesquelles elles contiennent des paramètres, sont exécutées?
Cela me semble être une question de philosophie de conception plus large que je vais diviser en deux. La première question concerne la valeur et la pertinence de l'utilisation de l'environnement Shell. At-il une valeur positive? Oui, c'est utile. Est-ce la meilleure solution à tous les problèmes de configuration? Non, mais il est très efficace pour gérer des paramètres simples, et également largement reconnu et compris. Contrairement à cela, décider de configurer de telles choses de manière hétérogène, peut-être que $ PATH pourrait être géré par un outil indépendant distinct, des outils préférés tels que $ EDITOR pourraient être dans un fichier sqlite quelque part, $ LC lang stuff pourrait être dans un fichier texte avec un format personnalisé ailleurs, etc - n'utilise pas seulement des variables env et /etc/profile.d semble soudain plus simple? Vous savez probablement déjà ce qu'est une variable env, comment elle fonctionne et comment l'utiliser, par rapport à l'apprentissage de 5 mécanismes complètement différents pour 5 aspects omniprésents de ce qui est correctement nommé "l'environnement".
La deuxième question est "Le démarrage est-il le moment approprié pour cela?", Ce qui soulève l'objection selon laquelle il n'est pas très efficace (toutes ces données qui peuvent ou non être utilisées, etc.). Mais:
- En réalité, ce ne sont pas tant de données, en partie parce que personne sensé ne les utiliserait pour plus que quelques paramètres simples (car il existe d'autres moyens de configurer une application).
- S'il est utilisé à bon escient, en ce qui concerne les choses qui sont couramment invoquées, alors, par exemple, définir $ CFLAGS par défaut à partir d'un fichier quelque part chaque fois que vous appelez
gccserait moins efficace. Gardez à l'esprit que la quantité de mémoire impliquée est, encore une fois, infinitésimale. - Il peut impliquer des choses systémiques avec lesquelles plus d'une application peuvent être impliquées, et le Shell est un terrain d'entente .
Plus pourrait être ajouté à cette liste, mais j'espère que cela vous donne une idée des avantages et des inconvénients du problème - le principal "pro" et le principal "con" étant qu'il s'agit d'un espace de noms mondial.
Ces fichiers sont spécifiques à une application, mais proviennent du démarrage de Shell, pas au démarrage de l'application. Un répertoire de configuration est utilisé ici pour la même raison qu'il se trouve dans de nombreux autres endroits. Cela permet à une application ou à un progiciel de modifier les configurations. Cela ne serait pas possible sans une configuration divisée, car plusieurs packages essayant de gérer/mettre à jour un seul fichier de configuration qui peut également être modifié par l'utilisateur seraient bogués et désordonnés.
Également une note latérale, /etc/profile provient de tous les shells, pas seulement de bash. Le fichier de configuration spécifique à bash est bashrc et ne provient que des shells interactifs.
réponse de jordanm est incorrect. /etc/profile n'est pas fourni par tous les shells. Comme vous le faites remarquer, il ne provient pas de csh, tcsh - je ne suis pas sûr de zsh. Il provient de dérivés de Bourne Shell (sh), comme Korn Shell (ksh) et BASH (bash). csh utilise /etc/login. Les personnes qui ont tendance à utiliser exclusivement des dérivés de Borne Shell ont tendance à oublier qu'il existe d'autres coques. Ils ajoutent quelque chose à /etc/profile s'attendant à ce qu'il s'applique à "tous les utilisateurs", puis ils sont surpris lorsque l'utilisateur étrange du shell C (et nous sommes un lot étrange) n'a pas les éléments qu'il a configurés dans /etc/profile.
Même ainsi, les gens ont tendance à oublier qu'il existe d'autres coques dérivées de Shell Borne. S'ils utilisent bash ou ksh, ils se sentent libres d'ajouter de la syntaxe à /etc/profile qui n'est pas valide dans Bourne Shell, comme par exemple définir une variable et l'exporter sur la même ligne. Ensuite, vous obtenez un script qui fait #!/bin/sh et ça étouffe la syntaxe. /etc/profile devrait s'en tenir à la syntaxe compatible avec Bourne Shell.
De même, vous devez vous y tenir dans votre propre .profile (utilisation .bash_profile si vous voulez une syntaxe bash) - cela peut être un peu de frappe supplémentaire, mais c'est une frappe supplémentaire que vous effectuez toutes une fois. Référence ${HOME} et pas ~, etc. Certaines versions d'Unix, les tâches cron s'exécutent sous sh, chaque ligne de votre Makefile est traitée par sh, donc si vous travaillez sur plusieurs versions d'UNIX, il vaut vraiment la peine de garder votre .profile Compatible Bourne Shell. En tant que SysAdmin, je ne peux pas vous dire combien de fois j'ai aidé quelqu'un en réparant son .profile pour être compatible Bourne Shell.
Sous Linux, /bin/sh est un lien vers /bin/bash et lorsque vous l'exécutez, il ressemble au chemin qui a été utilisé pour l'exécuter et (en théorie) se limite aux seules choses que Bourne Shell prend en charge. De même, vi sous Linux est vraiment vim, se limitant à nouveau. Parfois, vous voyez des fonctionnalités "saigner". Parfois, vim faisant semblant d'être vi fera quelque chose que vim prend en charge et que vi ne prend pas en charge, car les auteurs de vim ont oublié de désactiver cette option. en mode "vi compatibilité descendante". Je ne serais pas surpris si bash prétendant être sh a des fonctionnalités similaires de "purge". Je ne serais pas surpris si une fonctionnalité "fonctionne sur Borne Shell sous Linux", mais pas sur UNIX basé sur System V ou BSD (AIX, OpenBSD, etc.).