Cosa sono le shell di login e non login?


78

Si dice che le impostazioni per la shell non di login vadano nel .bashrcfile e le impostazioni della shell di login per andare nel .profilefile.

Cosa si intende realmente per shell di login e non login?

Spiegare senza utilizzare il gergo tecnico il più possibile.

Risposte:


83

In poche parole:

  • Se apri una shell o un terminale (o passi a uno) e ti chiede di accedere (Username? Password?) Prima che ti dia un prompt, è una shell di login.
  • In caso contrario (come gnome-terminal ), e ti consente di usarlo immediatamente, è una shell non di accesso.

Se sei un normale utente di Ubuntu Desktop, l' unica shell di accesso è ... il tuo desktop (inserisci una password per entrare, giusto;)? Bene, tecnicamente è una shell di login che avvia una GUI, ma sta entrando in gergo. E sì, leggerà le impostazioni in.profile

L'unica volta in cui tu (un normale utente) vedrai probabilmente una shell di accesso che assomiglia a una shell di accesso è se hai qualche problema con il tuo desktop e passi a un terminale virtuale con il collegamento Ctrl+ Alt+ F1.


Gli altri casi generali per avere una shell di login includono:

  • accedere al computer in remoto tramite ssh(o connettersi localmente con ssh localhost)
  • simulando una shell di login iniziale con bash -l(o sh -l)
  • simulando una rootshell di login iniziale consudo -i
    • o per un altro non utentesudo -u username -iroot
  • autenticazione come un altro non rootutente con (e la sua password)su - username
  • usando il sudo logincomando per cambiare utente

Se avvio il mio IDE Eclipse dal terminale, si apre come previsto, ma se provo ad aprirlo facendo clic sull'icona Eclipse, non è in grado di riconoscere la posizione Java (se non diversamente impostato PATH per Java nel file .profile). Ciò significa che facendo clic sull'icona Eclipse è necessaria una shell di accesso, perché?
DUKE,

2
@DUKE, No, significa che le variabili di ambiente devono essere impostate in modo diverso quando si utilizza un desktop / GUI rispetto a un vero sistema di console solo da riga di comando. Inserisci il tuo PERCORSO, ecc. ~/.pam_environment(Solo variabili, non ci sono comandi bash!), Disconnetti, accedi e guarda tutto ciò che appare magicamente sul desktop e in gnome-terminal!
Ish,

1
L'accesso tramite ssh non invoca una shell di accesso. Non carica /etc/profile, /etc/profile.doppure ~/.profile.
xuhdev,


@xuhdev Il login tramite ssh invoca una shell di login e carica / etc / profile, /etc/profile.d e ~ / .bash_profile.
MichaelZ,

9

Non credo che la risposta corretta possa essere data senza "gergo tecnico". Poiché questa domanda è la prima a comparire in Google per la query "che cos'è una shell di accesso", sto fornendo una risposta più corretta di seguito:

La shell di accesso è semplicemente una shell a cui è stato detto di essere una shell di accesso. Essa non significa guscio che si apre dopo l'accesso, anche se di solito applicazione che si registra nel sta dicendo shell si lancia ad essere una shell di login. Esistono i seguenti modi per dire alla shell che dovrebbe essere un login:

  1. Esecuzione di shell con -lo --loginargomento supponendo che lo sappia (non conosco alcuna shell che non conosca -l, ma --loginè supportata solo da poche shell).
  2. Esecuzione di shell con argv[0]set su -{some_string}(cioè con HYPHEN-MINUS anteposto al solito argv[0]o ad un'altra stringa). Questo è ciò che fanno ssh e su: su esegue solo eseguibile con -suas argv[0](ciao a tutti quelli che pensano argv[0]abbiano qualcosa a che fare con il nome eseguibile attualmente in esecuzione), ssh esegue zsh con -zshquando l'utente ha impostato /bin/zshcome shell.

La logicità della shell non ha assolutamente nulla a che fare con nessuno che ti chieda una password o esegua qualche altra procedura di autenticazione. Alcuni programmi come ssh o login (o alcuni emulatori di terminale come urxvt) eseguono shell come login usando argv[0]quello che inizia con HYPHEN-MINUS. Alcuni come su o sudo (o zsh: vedi il -modificatore di precomando descritto nella sezione MODIFICATORI PRECOMMAND in man zshmisc) non lo fanno per impostazione predefinita, ma può essere detto. Alcuni hanno l'unica opzione per dire alla shell di essere quella di accesso usando il suo argomento (es. bash -l): Ssh con un argomento di comando (che dice esplicitamente a ssh cosa eseguire sul terminale remoto).

Generalmente è meglio consultare prima la documentazione del programma utilizzato per invocare la shell per determinare se la shell sarà quella di accesso e in secondo luogo eseguire alcuni test per determinare se l'app avvierà una shell di accesso (ad esempio aggiungendo echoa .profile).


Sono interessato alla seconda opzione: come posso effettivamente cambiare argv [0] prima (o dopo) di invocare bash? Può essere fatto dalla riga di comando?
VeryHardCoder

@VeryHardCoder Dipende dall'applicazione utilizzata per eseguire il comando. Nel codice C si esegue fornendo direttamente argv[0]una delle exec*funzioni, naturale e inevitabile: si forniscono sempre sia il argv[0] percorso che il comando da eseguire effettivamente quando si usano le exec*funzioni, anche se non si vuole mai argv[0]essere diversi dall'esecuzione dei comandi. Altre lingue forniscono i propri modi. In particolare bash consente l'uso exec -a new_argv0 bash, ma questo, ovviamente, sostituirà la shell attualmente in esecuzione con qualsiasi cosa tu abbia execeditato, quindi potresti aver bisogno di usare subshell ( (exec -a -zsh zsh))
ZyX

Ok capito! In realtà, potrebbe essere fatto anche in un modo più semplice: (exec -l bash) ...
VeryHardCoder

1
Qual è la differenza funzionale tra i due? È semplicemente una bandiera booleana?
Alexey,

@Alexey La differenza funzionale principale è un insieme di file di configurazione utilizzati all'avvio. $0e, forse, anche qualcos'altro (variabile, impostazione, ecc.) è impostato in modo tale che il loginess della shell possa essere rilevato nel file di configurazione, ma chi si preoccupa effettivamente di rilevarlo in modo che possa fare la differenza? Questo è tutto quello che so.
ZyX,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.