Pourquoi 'tmux' crée-t-il de nouvelles fenêtres en tant que shell de connexion par défaut?


26

Lorsque vous démarrez une nouvelle session dans tmuxou créez une nouvelle fenêtre à l'intérieur d'une session en cours d'exécution, son comportement par défaut est d'exécuter un shell (ex. bash) En tant que shell de connexion.

Je comprends qu'un shell de connexion est destiné à exécuter une routine de configurations et de procédures qui sont intéressantes juste lorsque vous vous connectez à un système . Mais dans la majorité des cas (à l'exception que vous pouvez utiliser tmux comme shell de connexion), ce n'est pas la véritable intention de l'utilisateur de le faire lorsqu'il veut simplement ouvrir une nouvelle fenêtre.

Alors, quelle est la justification de ce comportement par défaut tmux?


La seule chose que la documentation dit à ce sujet:

default-command  shell-command
        Set the command used for new windows (if not specified when the
        window is created) to shell-command, which may be any sh(1)
        command.  The default is an empty string, which instructs tmux
        to create a login shell using the value of the default-shell
        option.

Réponses:


24

Le shell interactif sans connexion ne survit généralement jamais à votre shell de connexion de niveau supérieur, ils peuvent donc s'attendre à ce que toutes les installations démarrées par celui-ci soient disponibles à tout moment, mais ce n'est pas le cas avec tmux:

  • vous vous connectez à votre shell -> vos scripts de connexion sont exécutés
  • vous exécutez tmux, faites quelque chose, détachez
  • quittez votre shell de niveau supérieur -> vos scripts de déconnexion sont exécutés
  • La session tmux est toujours en cours d'exécution mais toutes les installations démarrées par votre shell de connexion ne sont pas disponibles pour le moment
  • vous vous reconnectez et vous vous reconnectez à partir d'un autre shell de connexion
  • toutes les installations démarrées par le nouveau shell de connexion peuvent ne pas être visibles par tmux car il fonctionne toujours avec l'ancien environnement (même s'il existe des commandes pour mettre à jour l'environnement)

Certains peuvent penser qu'avoir tmux démarrer les shells de connexion n'est de toute façon pas nécessaire car dans la plupart des configurations, il n'y a pas de scripts de déconnexion et les scripts de connexion configurent simplement certaines variables d'environnement.

De plus, si vous ajoutez des chaînes à vos variables d'environnement dans vos scripts de connexion (comme ceci: PATH = $ PATH: / some / other / path) et qu'elles sont exécutées plusieurs fois dans la même hiérarchie de processus, vous vous retrouvez avec des doublons, et ceci est le plus ennuyeux.

Mais j'ai toujours tendance à penser que la valeur par défaut est logique.

Voir aussi ceci: http://openbsd-archive.7691.n7.nabble.com/tmux-and-login-shells-td170948.html


2
Merci pour la réponse et pour le lien! Je pense que je peux vivre avec exec shà la fin ... (je n'avais pas pensé à ça.)
leogama

3
Avez-vous des exemples concrets de choses qui pourraient se casser si tmux ne générait pas de shell de connexion? Je pense à en faire mon défaut, mais je ne veux pas rencontrer de problèmes difficiles à diagnostiquer sur toute la ligne.
Carl Patenaude Poulin
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.