Que font les scripts de /etc/profile.d?

Je suis en train de lire sur les scripts shell basiques à partir de la ligne de commande Linux et de la Bible des scripts shell .

Il indique que le /etc/profilefichier définit les variables d'environnement au démarrage du shell Bash. Le /etc/profile.drépertoire contient d'autres scripts contenant 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 /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, 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?

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 dans un script géant?", La réponse est:

1. Parce que ce serait un cauchemar de maintenance pour les personnes responsables des scripts.
2. Étant donné que les scripts sont chargés en tant que modules indépendants, l'ensemble du système est ajustable de manière dynamique - des scripts individuels peuvent être ajoutés et supprimés sans affecter les autres. Etc.
3. Parce qu'ils sont chargés via / etc / profile, ce qui en fait une partie du "profil" bash de la même manière.

Si ces fichiers sont des fichiers de démarrage spécifiques à l'application qui ne sont pas essentiels au démarrage de Bash, 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 scinder 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 c'est très efficace pour gérer des paramètres simples, mais aussi largement reconnu et compris. Contrairement à dire, en décidant de configurer de telles choses de manière hétérogène, $ PATH pourrait peut-être être géré par un outil indépendant séparé, les outils préférés tels que $ EDITOR pourraient être quelque part dans un fichier sqlite, les éléments de $ LC lang pourraient être dans un fichier texte avec format personnalisé ailleurs, etc. - ne se limite pas à utiliser des variables env et/etc/profile.dsemble-t-il soudainement plus simple? Vous savez probablement déjà ce qu'est une variable env, comment elle fonctionne et comment l'utiliser, par opposition à l'apprentissage de 5 mécanismes complètement différents pour 5 aspects omniprésents de ce que l'on appelle correctement "l'environnement".

La deuxième question est "Le démarrage est-il le bon moment pour cela?", Ce qui soulève l'objection selon laquelle il n'est pas très efficace (toutes ces données pouvant ou non être utilisées, etc.). Mais:

• En réalité, il n’ya pas beaucoup de données, en partie parce que personne de bien ne les utiliserait pour plus que quelques paramètres simples (car il existe un autre moyen de configurer une application).
• S'il est utilisé à bon escient, en ce qui concerne les éléments invoqués couramment, définir, par exemple, $ CFLAGS par défaut à partir d'un fichier quelque part chaque fois que vous appelez gccserait moins efficace. N'oubliez pas que la quantité de mémoire impliquée est, encore une fois, infinitésimale.
• Il peut s'agir de problèmes systémiques auxquels plusieurs applications peuvent être associées, et le shell est un terrain d'entente .

D'autres éléments pourraient être ajoutés à cette liste, mais j'espère que cela vous donne une idée du pour et du contre de la question - le principal «pro» et le principal «con» étant qu'il s'agit d'un espace de noms global.

Ces fichiers sont spécifiques à une application, mais proviennent du démarrage du shell, et non du 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 fractionnée, car plusieurs packages essayant de gérer / mettre à jour un seul fichier de configuration pouvant également être modifié par l'utilisateur seraient bogués et compliqués.

Aussi une note de côté, /etc/profileprovient de tous les coquillages, pas seulement bash. Le fichier de configuration spécifique à bash est bashrc et provient uniquement des shells interactifs.

la réponse de jordanm est incorrecte. /etc/profilene provient pas de tous les obus. Comme vous le soulignez, il ne provient pas par csh, tcsh- Je ne suis pas sûr zsh. Il provient de shdérivés Bourne shell ( ), comme Korn Shell ( ksh) et BASH ( bash). cshutilise /etc/login. Les personnes qui ont tendance à utiliser exclusivement des dérivés de Borne Shell ont tendance à oublier que d’autres coquilles existent. Ils ajoutent quelque chose à /etc/profileattendre de s’appliquer à «tous les utilisateurs» et sont ensuite surpris lorsque l’utilisateur impair de C Shell (et nous sommes un lot étrange) n’a pas les éléments qu’il a configurés /etc/profile.

Même dans ce cas, les gens ont tendance à oublier qu’il existe d’autres coquilles dérivées de Borne Shell. S'ils utilisent bashou ksh, ils se sentent libres d'ajouter une syntaxe /etc/profilequi 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/shet cela étouffe la syntaxe. /etc/profiledevrait s'en tenir à la syntaxe compatible Bourne Shell.

De même, vous devriez vous en tenir à votre propre .profileusage (à utiliser .bash_profilesi vous voulez une syntaxe bash) - cela peut être un peu de frappe supplémentaire, mais c'est une frappe supplémentaire que vous faites une fois. Référence ${HOME}et non ~, etc. Certaines variantes de tâches Unon, cron s'exécutent sh, chaque ligne de votre Makefileest traitée par sh. Par conséquent, si vous travaillez sur plusieurs versions d'UNIX, il est très utile de garder votre .profileshell Bourne compatible. En tant qu'administrateur système, je ne peux pas vous dire combien de fois j'ai aidé des personnes en les .profilerendant compatibles avec Bourne Shell.

Sous Linux, /bin/shest un lien vers /bin/bashet lorsque vous l'exécutez, il recherche le chemin utilisé pour l'exécuter et (en théorie) se limite aux éléments pris en charge par Bourne Shell. De même, visur Linux se vimlimite vraiment , encore une fois. Parfois, vous voyez des fonctionnalités "saigner à travers". Parfois, vimprétendre être vifera quelque chose qui le vimsupporte, vicar les auteurs de ont vimoublié de le désactiver en mode "compatibilité ascendante vi". Je ne serais pas surpris si vous bashprétendez être shdoté de fonctionnalités similaires. Ne seriez pas surpris si certaines fonctionnalités "fonctionnent sur Borne Shell sous Linux", mais pas sous UNIX basé sur System V ou BSD (AIX, OpenBSD, etc.).