O que são shells de login e não-login?

Dizem que as configurações para o shell que não é de login entra no .bashrcarquivo e as configurações do shell de login para entrar no .profilearquivo.

O que realmente se entende por shells de login e não-login?

Por favor, explique sem usar o jargão técnico, tanto quanto possível.

— DUQUE
fonte

Respostas:

Simplificando:

Se você abrir um shell ou terminal (ou alternar para um) e solicitar que você efetue login (Nome de usuário? Senha?) Antes de fornecer uma solicitação, é um shell de login.
Se não funcionar (como o gnome-terminal ) e permitir que você o use imediatamente, é um shell que não é de login.

Se você é um usuário normal do Ubuntu Desktop, o único shell de login é ... sua área de trabalho (você digita uma senha para entrar, certo;)? Bem, tecnicamente, é um shell de login que inicia uma GUI, mas isso está chegando ao jargão. E sim, ele lerá as configurações em.profile

A única vez em que você (um usuário normal) provavelmente verá um shell de login que se parece com um shell de login é se você estiver tendo algum problema com a área de trabalho e mudar para um terminal virtual com o atalho Ctrl+ Alt+ F1.

Os outros casos gerais de ter um shell de login incluem:

acessar seu computador remotamente via ssh(ou conectar-se localmente com ssh localhost)
simulando um shell de login inicial com bash -l(ou sh -l)
simulando um rootshell de login inicial comsudo -i
- ou para outro não usuáriosudo -u username -iroot
autenticação como outro não rootusuário com (e sua senha)su - username
usando o sudo logincomando para alternar usuário

— ish
fonte

Se eu iniciar o meu Eclipse IDE a partir do terminal, ele será aberto conforme o esperado, mas se eu tentar abri-lo clicando no ícone Eclipse, ele não poderá reconhecer a localização do Java (a menos que o PATH for Java esteja definido no arquivo .profile). Isso significa que clicar no ícone do Eclipse precisa de um shell de login, por quê?

— DUKE

@DUKE, Não, isso significa que as variáveis de ambiente precisam ser definidas de maneira diferente quando você está usando uma área de trabalho / GUI em comparação com um verdadeiro sistema de console somente de linha de comando. Coloque seu PATH, etc. em ~/.pam_environment(apenas variáveis, sem comandos bash!), Faça logout, faça login e observe tudo aparecer magicamente na área de trabalho e também no terminal gnome!

— Ish

O login via ssh não chama um shell de login. Não carrega /etc/profile, /etc/profile.dou ~/.profile.

— xuhdev

Veja esta pergunta .

— xuhdev

@xuhdev O login via ssh invoca um shell de login e carrega / etc / profile, /etc/profile.d e ~ / .bash_profile.

— MichaelZ

Eu não acho que a resposta correta possa ser dada sem "jargão técnico". Como esta pergunta é a primeira a aparecer no Google para a consulta "o que é um shell de login", estou fornecendo uma resposta mais correta abaixo:

O shell de login é simplesmente um shell que foi dito para ser um shell de login. Isso não significa que o shell apareça após o login, embora normalmente o aplicativo que efetua o login esteja dizendo ao shell que ele é iniciado. Existem as seguintes maneiras de informar ao shell que ele deve ser de login:

Executando shell com -lou --loginargumento, assumindo que ele conhece (não conheço nenhum shells que não conheço -l, mas --loginsó é suportado por alguns shells).
Executando o shell com argv[0]definido como -{some_string}(ou seja, com HYPHEN-MINUS anexado ao habitual argv[0]ou a alguma outra string). Isto é o que o ssh e o su fazem: su apenas executa o executável com -suas argv[0](olá para todos que pensam argv[0]ter algo a ver com o nome do executável atualmente em execução), o ssh executa o zsh -zshquando o usuário define /bin/zshcomo seu shell.

A lógica do shell não tem absolutamente nada a ver com alguém pedindo uma senha ou executando outro procedimento de autenticação. Alguns programas como o ssh ou o login (ou alguns emuladores de terminal como o urxvt) executam shells como os de login argv[0]que começam com um HYPHEN-MINUS. Alguns como su ou sudo (ou zsh: veja o -modificador de pré-comando descrito na seção PRECOMMAND MODIFIERS in man zshmisc) não fazem isso por padrão, mas podem ser informados. Alguns têm a única opção de dizer ao shell para o login usando seu argumento (ie bash -l): ssh com um argumento de comando (que explicitamente diz ao ssh o que executar no terminal remoto).

Geralmente, é melhor consultar primeiro a documentação do programa usado para chamar o shell para determinar se o shell será o primeiro login e, em seguida, realizar alguns testes para determinar se o aplicativo iniciará um shell de login (por exemplo, adicionando echoa .profile).

— ZyX
fonte

Estou interessado na segunda opção: como posso realmente alterar argv [0] antes (ou depois) de invocar o bash? Isso pode ser feito a partir da linha de comando?

— VeryHardCoder

@VeryHardCoder Isso depende do aplicativo que você usa para executar o comando. No código C, isso é feito fornecendo diretamente argv[0]a uma das exec*funções, naturais e inevitáveis: você sempre fornece o argv[0] caminho para o comando realmente executado ao usar as exec*funções, mesmo que você nunca deseje argv[0]ser diferente da execução do comando. Outros idiomas fornecem seus próprios caminhos. Especificamente o bash permite usar exec -a new_argv0 bash, mas isso, é claro, vai substituir atualmente em execução shell com o que você execED, assim você pode precisar de usar subshell ( (exec -a -zsh zsh))

— Zyx

OK, entendi! Na verdade, isso poderia ser feito mesmo em uma maneira mais simples: (exec festa -l) ...

— VeryHardCoder

Qual é a diferença funcional entre os dois? Isso é simplesmente uma bandeira booleana?

— Alexey

@Alexey A principal diferença funcional é um conjunto de arquivos de configuração usados na inicialização. $0, e, talvez também algo mais (variável, configuração etc.) esteja definido para que a lógica do shell possa ser detectada no arquivo de configuração, mas quem se incomoda em detectá-lo para que isso faça alguma diferença? Isso é tudo que eu sei.

— ZyX 9/10