Pourquoi avons-nous des shells bash de connexion, sans connexion, interactifs et non interactifs?

23

Ainsi, les pages de manuel bash expliquent ce que sont les shells de connexion et interactifs:

Un shell de connexion est un shell dont le premier caractère de l'argument zéro est un -, ou un commençant par l'option --login.

Un shell interactif est un shell démarré sans arguments sans option et sans l'option -c dont l'entrée standard et l'erreur sont tous deux connectés aux terminaux (comme déterminé par isatty (3)), ou un ordinateur démarré avec l'option -i. PS1 est défini et $ - inclut i si bash est interactif, permettant à un script shell ou à un fichier de démarrage de tester cet état.

Je pense que cela signifie que nous pouvons avoir 4 types de coques différents:

  • Coques de connexion interactives,
  • Coques de connexion non interactives,
  • Shells interactifs sans connexion,
  • Shells non interactifs sans connexion

Mais pourquoi avons-nous des shells interactifs / non interactifs et de connexion / non-connexion en premier lieu? Pourquoi la variété? Que perdrions-nous si nous n'avions qu'un seul type d'obus?

De plus, lorsque j'essaie de déterminer si je suis dans un shell de connexion en exécutant echo $-, il génère:

himBH

Certains de ces drapeaux sont expliqués ici , mais h, Het mne sont pas expliquées. Y a-t-il un endroit qui décrit tous ces drapeaux?

TheFooProgrammer
la source

Réponses:

21

Ce sont mes réflexions sur les différents "types" de coquilles - malheureusement, je n'ai pas assisté à la montée de l'Un * x dès le début (je suppose que ce concept a grandi historiquement dans une bonne mesure), alors soyez critique.

  • Lorsque je me connecte à un système (de nos jours via la connexion graphique X), certaines tâches doivent être exécutées une seule fois, par exemple établir une connexion avec une sorte de serveur, me présenter une liste de tâches du jour, démarrer automatiquement certaines commandes, etc. ne devrait pas arriver chaque fois que j'ouvre un nouveau terminal. Il existe donc un ensemble de fichiers de configuration ( /etc/profile, ~/.bash_loginet ainsi de suite, reportez-vous au manuel pour une liste précise) provenant uniquement des shells de connexion .
  • Par conséquent, pour fermer les connexions, tuer certains programmes, exécuter un script de sauvegarde ~/.bash_logoutlorsque le shell de connexion existe.
  • donc, la « normale » shell - je utiliser dans un terminal, ne doit pas ba une connexion shell, mais devraient néanmoins lire de mes préférences personnelles ~/.bashrc, parce que je veux que mes raccourcis clavier pour interagir avec le shell - où cela est une interactive, non shell de connexion .
  • et enfin, mais pas le moindre lorsque bash est utilisé pour l'écriture de scripts, rien de tout cela n'est important. bashdevrait démarrer aussi vite que possible, c'est-à-dire ne devrait lire aucun fichier de configuration. Il s'agit d'un shell non interactif et sans connexion .

Donc, ma réponse à votre question Que perdrions-nous si nous n'avions qu'un seul type d'obus? est en un mot: "Flexibilité".


La réponse à votre deuxième question est simple:

$-répertorie l'ensemble actuel d'options. Celles-ci peuvent être définies par des paramètres de ligne de commande sur bashou via le setmodule intégré. Il faut donc regarder deux endroits dans le manuel:

  • OPTIONS section:

    -i        If the -i option is present, the shell is interactive.
  • SHELL BUILTIN COMMANDSsection, sous-section set:

    -h      Remember the location of commands as they are looked up for execution.  This is enabled by default.
    -m      Monitor  mode.  Job control is enabled.  This option is on by default for interactive shells on systems that sup
            port it (see JOB CONTROL above).  Background processes run in a separate process  group  and  a  line  containing
            their exit status is printed upon their completion.
    -B      The shell performs brace expansion (see Brace Expansion above).  This is on by default.
    -H      Enable !  style history substitution.  This option is on by default when the shell is interactive.
mpy
la source
1
Woo Je crois que la réponse de @mpy à la question clairement formulée de OP est capable de désambiguiser avec succès une définition plutôt utile. À ce sujet: un shell sans connexion n'est donc qu'un sous - ensemble du shell de connexion, n'est-ce pas?
tuk0z