A ideia é que um usuário tenha (no máximo) um shell de login por host. (Talvez eu deva dizer, um shell de login por host por terminal - se você estiver conectado simultaneamente a um host por vários terminais, esperaria ter vários shells de login.) Esse normalmente (sempre?) Seria o primeiro shell a ser obtido ao fazer login (daí o nome). Portanto, esse esquema permite que você especifique as ações que deseja que ocorram apenas uma vez por login e as que deseja que ocorram toda vez que iniciar um novo shell (interativo).
Normalmente, todos os outros shell executados após o login serão descendentes (filhos de um filho de um filho ...) do shell de logon e, portanto, herdarão muitas configurações (variáveis de ambiente umasketc.) do shell de logon. E, consequentemente, a idéia é que os arquivos de inicialização login ( .login, .profile, etc.) deve definir as configurações que são herdadas, e deixar .bashrc(ou qualquer outra coisa que você usa) lidar com os que não são ( set, shopt, variáveis do shell não exportados etc.)
Outra noção é que os arquivos de inicialização do logon (e somente eles) devem fazer "trabalho pesado", ou seja, ações que consomem muitos recursos. Por exemplo, convém ter certos processos em execução em segundo plano sempre que estiver conectado (mas apenas uma cópia (instância) deles). Você pode querer exibir algumas informações de status (por exemplo, dfou who) ao fazer login, mas não sempre que iniciar um novo shell interativo. Especialmente se você tiver um interativoprograma / caixa de diálogo (ou seja, que exija informações suas) que você deseja executar toda vez que fizer login, provavelmente não deseja executá-lo toda vez que iniciar um novo shell. Como exemplo extremo, há vinte anos, o Solaris efetuou login em um único shell não gráfico e sem janelas. (Eu acredito que mudou desde então.) Foi o trabalho de .loginou .profile(ou qualquer outro) para iniciar o sistema de janelas, com um comando como startx. (Isso foi útil em parte porque havia vários sistemas de janelas disponíveis. Usuários diferentes tinham preferências diferentes. Alguns usuários usaram sistemas diferentes em situações diferentes, e tivemos uma caixa de diálogo na .profilequal perguntamos "Qual sistema de janelas você deseja usar hoje?") Obviamente, você não gostaria que isso fosse executado toda vez que você abrir uma nova janela ou digitarsh.
Já faz muito tempo que não uso nada além de bash
casos extremos. (Por exemplo, eu escrevo scripts com #!/bin/sh, em alguns sistemas, meus scripts são executados com dashe em outros com o bashmodo POSIX. Algumas vezes por ano eu corro csh/ tcshpor alguns minutos para ver como ele lida com alguma coisa ou para responda a uma pergunta.) Se você usar várias conchas (por exemplo, bashe zsh) diariamente, seus padrões podem ser diferentes. Se o seu shell principal (como definido em /etc/passwd) for bash, convém chamar um zshshell de login e, em seguida, talvez invocar alguns zshshells interativos sem login subordinados a isso. Você provavelmente deve evitar ter um shell de logon subordinado a outro shell de logon do mesmo tipo.
Como mencionado na diferença entre o shell de login e o shell que não é de login? , o aplicativo OS X Terminal executa um shell de logon; portanto, um usuário típico normalmente possui várias "shells de logon" em execução simultaneamente. Este é um modelo um pouco diferente do que eu descrevi acima, e pode exigir o usuário a repensar o que ele faz em seu .loginou.profile(ou o que for) arquivo. Não sei se os desenvolvedores do OS X documentaram sua lógica para esta decisão de design. Mas posso imaginar uma situação em que isso seria útil. Houve um tempo em que eu normalmente abria algumas janelas do shell quando fazia o login e as definia com diferentes cores de texto e plano de fundo (escrevendo sequências de escape ANSI na tela) para me ajudar a controlar qual era qual. As cores dos terminais são um exemplo de algo que não é herdado por filhos, mas persiste em uma janela. Portanto, esse é o tipo de coisa que você deseja fazer sempre que iniciar uma nova janela do Terminal, mas não sempre que iniciar um novo shell interativo.