Por que o / etc / profile não é chamado para shells que não são de login?

Shell de logon e não logon definido como:

su - $USER # will give you a login shell
bash # will give you a non-login shell

/ etc / profile não é chamado para shells que não são de login, como quando você inicia o konsole (kde). / etc / profile é invocado apenas para shells de login.

Por que é que? Por favor, explique, porque eu gosto de entender a lógica disso.

/etc/profile é chamado apenas para shells de logon porque esse é seu objetivo específico.

Se você deseja que um comando seja executado para shells interativos que não são shells de logon e estiver usando bash, insira-o ~/.bashrcou /etc/bash.bashrc.

O objetivo dos arquivos "perfil" é conter comandos que devem ser executados apenas para shells de login. Esses arquivos são:

• /etc/profile, executado por todos os shells compatíveis com Bourne (incluindo bashe dash) quando iniciado como um shell de logon.

• Scripts em /etc/profile.d.

  Isso é para shells no estilo Bourne, mas não é codificado no próprio executável do shell. Em vez disso, os comandos os /etc/profilechamam. Por exemplo, no meu sistema Ubuntu 12.04, /etc/profileinclui estas linhas:

  if [ -d /etc/profile.d ]; then
    for i in /etc/profile.d/*.sh; do
      if [ -r $i ]; then
        . $i
      fi
    done
    unset i
  fi
  

• .profile no diretório inicial do usuário, executado por shells compatíveis com Bourne quando iniciado como um shell de logon (a menos que seja substituído, veja abaixo).

• .bash_profileou .bash_loginno diretório inicial do usuário. Estes são ignorados por conchas que não sejam bash. Mas se .bash_profileexistir, bashexecute-o em vez de .profile . Se .bash_profilenão existe, mas .bash_loginexiste, é executado em vez de .profile.

  (Mas é comum .bash_profileou .bash_login, quando existe, ser escrito para * chamar explicitamente .profile).

  O benefício dos arquivos de perfil específicos do shell é que eles podem conter comandos ou sintaxe válidos apenas para esse shell. Por exemplo, eu posso usar o [[operador de avaliação em .bash_profile/, .bash_loginmas se eu o usar .profilee depois efetuar login dashcomo meu shell, ele falhará.

O que deve aparecer nos arquivos "profile"

Os arquivos "profile" devem conter comandos que devem ser executados apenas uma vez, no início do login. (Isso inclui logins gráficos, pois também começam com um shell de logon.) Se um shell é interativo, o usuário que o executa provavelmente está conectado e, portanto, provavelmente possui um ancestral (que o iniciou ou iniciou o que o iniciou, ou iniciado, etc.) que era um shell de login.

Você pode querer executar um comando apenas uma vez porque:

1. não há motivo para executá-lo mais de uma vez por login, seria ineficiente ou
2. produziria um resultado indesejado, para executá-lo mais de uma vez por login.

Como um exemplo da segunda situação, onde um resultado indesejável ocorreria, considere estas linhas, que aparecem por padrão em todos os usuários ~/.profile:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Suponha que você entrou no SSH, executou outro shell (digamos zsh), em algum momento descobriu que queria voltar temporariamente para, bashmas manter seu ambiente (executou bashnovamente enquanto estava no zsh) e, em seguida, executou um programa como mcesse que executa um shell como parte da sua interface. Se binexiste na sua pasta pessoal e o seu nome de usuário é james, o seu PATHno shell mais interno é algo como:

/home/james/bin:/home/james/bin:/home/james/bin:/home/james/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Isso é ineficiente e (muito mais importante) dificulta a compreensão do conteúdo PATH.

Isso não é de forma alguma um desastre. Até onde eu sei, se todo shell interativo fornecesse arquivos de "perfil", nada de terrível aconteceria na configuração padrão . No entanto, como o objetivo dos arquivos "perfil" é conter comandos para serem executados apenas uma vez por logon , um usuário ou administrador pode adicionar comandos a um perfil que deve ser executado apenas ao iniciar um shell de logon.

Onde Colocar Comandos para Todo Shell Interativo Executar

Se você estiver usando bash, existem arquivos para comandos que devem ser executados em todos os shell interativos:

• /etc/bash.bashrc
• .bashrc no diretório inicial do usuário.

Isso é mais comumente usado para comandos que

1. afetam apenas o ambiente da concha em que são executadas - nem mesmo as conchas de crianças, ou
2. deve funcionar mesmo quando este não é o shell de login.

Por exemplo, a conclusão da guia da linha de comando geralmente deve ser ativada, independentemente de basho shell de logon ser ou não . Portanto, isso aparece em ~/.bashrc:

if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
    . /etc/bash_completion
fi

Lá, 1 e 2 se aplicam: isso não é transferido para outros shells executados dentro deste e o preenchimento de guias deve funcionar bashmesmo que eu tenha feito login com um shell diferente.

Onde colocar comandos para shells de login e shells interativos que não são de login

Se você estiver usando bashe quiser que um comando seja executado em shells de login e shells interativos e que não sejam shells de login, geralmente é suficiente colocá-lo em /etc/bash.bashrcou~/.bashrc . Isso ocorre por padrão /etc/profilee ~/.profileexecute-os explicitamente. Por exemplo, ~/.profilepossui:

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
        . "$HOME/.bashrc"
    fi
fi

(Da mesma forma, /etc/profilefontes /etc/bash.bashrcpara bash.)

Portanto, os arquivos "profile" e "rc" são executados quando você inicia um bashshell interativo (seja um shell de login ou não).

Onde colocar comandos para executar em shells não interativos

Você provavelmente não deseja especificar nenhum comando para que todos os shells não interativos sejam executados; eles seriam executados toda vez que um script fosse executado (desde que o script fosse executado pelo shell que você configurou para executá-los).

Isso pode causar uma quebra substancial. Se você fizer isso e não houver uma conta de administrador no sistema além da que você está usando, convém criar uma; isso pode facilitar a correção de erros.

Na bashverdade, os arquivos "rc" são executados independentemente de o shell ser interativo ou não . No entanto, no topo eles dizem:

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

Portanto, se você precisar que os comandos sejam executados automaticamente, mesmo em shells não interativos, como os que são executados para executar scripts, poderá adicionar seus comandos antes dessas linhas.

Iniciando um Shell de Login

O login inicia um shell de login. Se você quer um shell começou depois que a comportar-se como um shell de login, inicie-o com a -lbandeira (que significa l ogin ). Por exemplo:

• sh -l
• bash -l
• pdksh -l

Essa é a melhor maneira de iniciar um shell de login (sem fazer login), a menos que você queira iniciar um como outro usuário. Então, use:

• sudo -ifor root(use sudo -spara um shell raiz interativo sem logon)
• sudo -u username -i para qualquer usuário
• su - usernamepara não rootusuários (use para um shell raiz interativo sem login)su username

O que é um shell de login inicial ?

Um shell de login inicial é o mesmo que um shell de login . Em todos os lugares em que essa resposta diz "shell de login", pode-se dizer "shell de login inicial" (exceto nesta seção, que já teria parado de fazer sentido).

Uma razão para o termo shell de login inicial é que o shell de login também é usado em um sentido diferente - para identificar qual programa é usado como o shell que é executado ao fazer logon. Este é o sentido do shell de login usado para dizer:

• " O shell de login padrão do OpenBSD é ksh; no Ubuntu, é bash."
• "Você pode alterar seu shell de login com chsh."

Leitura adicional

• "Arquivos de configuração para shells" no "shell Unix" (Wikipedia)
• bash manpage
• Manual completo do bash (GNU)