L'idée est qu'un utilisateur doit avoir (au plus) un shell de connexion par hôte. (Peut-être devrais-je dire, un shell de connexion par hôte par terminal - si vous êtes connecté simultanément à un hôte via plusieurs terminaux, vous vous attendez à avoir plusieurs shells de connexion.) Ce serait généralement (toujours?) Le premier shell que vous obtenez lors de la connexion (d'où le nom). Ainsi, ce schéma vous permet de spécifier les actions que vous souhaitez effectuer une seule fois par connexion et les choses que vous souhaitez que chaque fois que vous démarrez un nouveau shell (interactif).
Normalement, chaque autre shell que vous exécutez après vous être connecté sera un descendant (enfant d'un enfant d'un enfant…) du shell de connexion, et héritera donc de nombreux paramètres (variables d'environnement umask, etc.) du shell de connexion. Et, par conséquent, l'idée est que les fichiers d'initialisation de connexion ( .login, .profile, etc.) doivent définir les paramètres qui sont héritables, et laisser .bashrc(ou tout ce que vous utilisez) gérer ceux qui ne sont pas ( set, shopt, variables shell non exportées , etc.)
Une autre notion est que les fichiers d'initialisation de connexion (et seulement eux) doivent effectuer des «tâches lourdes», c'est-à-dire des actions gourmandes en ressources. Par exemple, vous pouvez souhaiter que certains processus s'exécutent en arrière-plan chaque fois que vous êtes connecté (mais une seule copie (instance) d'entre eux). Vous souhaiterez peut-être que certaines informations d'état (par exemple, dfou who) s'affichent lorsque vous vous connectez, mais pas à chaque démarrage d'un nouveau shell interactif. Surtout si vous avez un interactifprogramme / boîte de dialogue (c.-à-d., un programme qui exige de votre part) que vous souhaitez exécuter à chaque fois que vous vous connectez, vous ne voulez probablement pas l'exécuter à chaque fois que vous démarrez un nouveau shell. À titre d'exemple extrême, il y a vingt ans, Solaris vous connectait à un seul shell, non graphique, sans fenêtre. (Je crois que cela a changé depuis.) C'était le travail de .loginou .profile(ou autre) de démarrer le système de fenêtrage, avec une commande comme startx. (Cela était utile en partie parce qu'il y avait plusieurs systèmes de fenêtrage disponibles. Différents utilisateurs avaient des préférences différentes. Certains utilisateurs utilisaient différents systèmes dans différentes situations, et nous avons eu une boîte de dialogue dans notre .profilequi a demandé "Quel système de fenêtrage voulez-vous utiliser aujourd'hui?") De toute évidence, vous ne voudriez pas que cela s'exécute à chaque fois que vous ouvrez une nouvelle fenêtre ou que vous tapezsh.
Cela fait longtemps que je n'ai rien utilisé d'autre que des bash
cas de bord. (Par exemple, j'écris des scripts avec #!/bin/sh, donc sur certains systèmes, mes scripts s'exécutent avec dash, et sur d'autres avec bashlesquels ils s'exécutent en mode POSIX. Quelques fois par an, j'exécute csh/ tcshpendant quelques minutes pour voir comment il gère quelque chose, ou pour répondre à une question.) Si vous utilisez plusieurs coques (par exemple, bashet zsh) quotidiennement, vos schémas peuvent être différents. Si votre shell principal (tel que défini dans /etc/passwd) est bash, vous voudrez peut-être invoquer un zshshell de connexion, puis peut-être invoquer des zshshells interactifs sans connexion subordonnés à cela. Vous devriez probablement éviter d'avoir un shell de connexion subordonné à un autre shell de connexion du même type.
Comme mentionné dans Différence entre le shell de connexion et le shell sans connexion? , l'application OS X Terminal exécute un shell de connexion, donc un utilisateur type aura généralement plusieurs «shells de connexion» exécutés simultanément. Ce modèle est un peu différent de celui que je l' ai décrit ci - dessus, et peut obliger l'utilisateur à repenser ce qu'il fait dans son .loginou.profile(ou autre) fichier. Je ne sais pas si les développeurs d'OS X ont documenté leur justification de cette décision de conception. Mais je peux imaginer une situation dans laquelle cela serait utile. Il fut un temps où j'ouvrais habituellement une poignée de fenêtres shell lorsque je me connectais, et je les définissais sur différentes couleurs de texte et d'arrière-plan (en écrivant des séquences d'échappement ANSI à l'écran) pour m'aider à garder une trace de laquelle. Les couleurs des terminaux sont un exemple de quelque chose qui n'est pas hérité par les enfants d'enfants, mais qui persiste dans une fenêtre. C'est donc le genre de chose que vous voudriez faire chaque fois que vous démarrez une nouvelle fenêtre Terminal, mais pas chaque fois que vous démarrez un nouveau shell interactif.