PERCHÉ una shell ** login ** su una shell ** non login **?


24

Ho una conoscenza di base dei dotfile nel sistema * nix. Ma sono ancora abbastanza confuso su questa differenza tra Shell di accesso e Shell non di accesso?

Una serie di risposte diverse (inclusi più duplicati) hanno già indirizzato i seguenti punti elenco:

  • Come invocare una shell di login o non login
  • Come rilevare una shell di login o non login
  • Quali file di avvio verranno utilizzati da una shell di accesso o non di accesso
  • Riferito alla documentazione (ad es. man bash) Per maggiori dettagli

Ciò che le risposte non hanno detto (e anche qualcosa di cui sono ancora confuso) è:

  • Qual è il caso d' uso di una shell di login o non login ? (ad esempio, ho configurato solo zshrcper zshe questo è sufficiente per la maggior parte esigenza dev personale, so che non è così semplice come quello che vimrca vim)

  • Qual è la ragione per usare un login su una shell non login (oltre a consumare diversi file di avvio e cicli di vita)?

Risposte:


15

L'idea è che un utente dovrebbe avere (al massimo) una shell di accesso per host. (Forse dovrei dire, una shell di accesso per host per terminale - se si è contemporaneamente connessi a un host attraverso più terminali, ci si aspetterebbe di avere più shell di accesso.) In genere (sempre?) Sarebbe la prima shell che si ottiene al momento dell'accesso (da qui il nome). Quindi, questo schema ti consente di specificare le azioni che vuoi che accadano una sola volta per login e le cose che vuoi che accadano ogni volta che avvii una nuova shell (interattiva).

Normalmente, ogni altra shell eseguita dopo l'accesso sarà un discendente (figlio di un figlio di un figlio ...) della shell di accesso e quindi erediterà molte impostazioni (variabili di ambiente umask, ecc.) Dalla shell di accesso. E, di conseguenza, l'idea è che i file di inizializzazione di login ( .login, .profile, etc.) dovrebbero definire le impostazioni che sono ereditabili, e lasciare .bashrc(o qualsiasi altra cosa si usa) gestire quelli che non sono ( set, shopt, variabili di shell non esportati , eccetera.)

Un'altra idea è che i file di inizializzazione del login (e solo loro) dovrebbero fare un "sollevamento pesante", cioè azioni ad alta intensità di risorse. Ad esempio, potresti voler avere determinati processi in esecuzione in background ogni volta che accedi (ma solo una copia (istanza) di essi). Potresti voler visualizzare alcune informazioni sullo stato (ad es. dfO who) quando accedi, ma non ogni volta che avvii una nuova shell interattiva. Soprattutto se hai un interattivoprogramma / finestra di dialogo (cioè, uno che richiede input da te) che vuoi eseguire ogni volta che accedi, probabilmente non vorrai farlo funzionare ogni volta che avvii una nuova shell. A titolo di esempio estremo, venti anni fa Solaris ha effettuato l'accesso a una singola shell non grafica, senza finestre. (Credo che sia cambiato da allora.) E 'stato il lavoro .logino .profile(o qualsiasi altra cosa) per avviare il sistema a finestre, con un comando come startx. (Ciò è stato utile in parte perché c'erano più sistemi di finestre disponibili. Utenti diversi avevano preferenze diverse. Alcuni utenti usavano sistemi diversi in situazioni diverse e avevamo una finestra di dialogo .profileche chiedeva "Quale sistema di finestre vuoi usare oggi?") Ovviamente, non vorrai che funzionasse ogni volta che aprivi una nuova finestra o scrivevish.

Sono passati secoli da quando ho usato qualsiasi cosa bash tranne che per i casi limite. (Ad esempio, scrivo script con #!/bin/sh, quindi su alcuni sistemi, i miei script funzionano con dash, e su altri funzionano con bashin modalità POSIX. Alcune volte all'anno corro csh/ tcshper alcuni minuti per vedere come gestisce qualcosa, o per rispondi a una domanda.) Se usi più shell (ad es. bashe zsh) su base giornaliera, i tuoi schemi potrebbero essere diversi. Se la tua shell primaria (come definita in /etc/passwd) è bash, potresti voler invocare una zshshell di login e quindi forse invocare alcune zshshell interattive non di login subordinate a quella. Probabilmente dovresti evitare di avere una shell di accesso subordinata a un'altra shell di accesso dello stesso tipo.

Come menzionato in Differenza tra Shell di accesso e Shell non di accesso? , l'applicazione Terminale OS X esegue una shell di accesso, quindi un utente tipico avrà in genere più "shell di accesso" in esecuzione contemporaneamente. Questo è un modello un po 'diverso da quello che ho descritto sopra e potrebbe richiedere all'utente di ripensare a ciò che fa nel suo .logino.profile(o qualunque altra cosa) file. Non so se gli sviluppatori di OS X abbiano documentato la loro logica per questa decisione di progettazione. Ma posso immaginare una situazione in cui ciò sarebbe utile. C'è stato un momento in cui ho aperto abitualmente una manciata di finestre shell quando ho effettuato l'accesso e li ho impostati su diversi colori di testo e di sfondo (scrivendo sequenze di escape ANSI sullo schermo) per aiutarmi a tenere traccia di quale fosse. I colori terminali sono un esempio di qualcosa che non è ereditato dai figli dei bambini, ma che persiste all'interno di una finestra. Quindi questo è il genere di cose che vorresti fare ogni volta che avvii una nuova finestra Terminale, ma non ogni volta che avvii una nuova shell interattiva.

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.