Voici un peu plus d'informations sur ce qui se passe, d'un point de vue Unix de niveau inférieur. C'est long et va au-delà de ce que vous avez demandé, mais cela peut être intéressant pour vous ou pour quelqu'un d'autre qui passe sur cette page.
Si vous regardez le w manuel de la commande ( man w ), il est dit que "l'utilitaire w imprime un résumé de l'activité actuelle du système, y compris ce que fait chaque utilisateur". C'est un peu vague, et un peu trompeur. Plus précisément, ce que w est de vous informer sur l'actualité logins . Les connexions sont enregistrées dans un fichier nommé /var/run/utmpx . Il existe des méthodes de bibliothèque communes pour mettre à jour utmpx de sorte que chaque programme qui doit enregistrer ou supprimer un login utilise la même procédure.
w lit le utmpx à l'aide de ces routines de bibliothèque communes et affiche des informations sur les sessions de connexion en cours, ainsi que le nom de l'utilisateur. processus de premier plan . Une session de connexion peut faire plusieurs choses à la fois, mais un seul programme est au premier plan. Tous les autres sont à l'arrière-plan, ce qui est le cas lorsque vous mettez une balise & sur votre commande ou appuyez sur control-Z pendant qu'un programme s'exécute dans un terminal.
Une session de connexion est créée lorsque vous vous connectez à votre ordinateur sur l'écran intégré. Si le changement d'utilisateur est activé, une connexion est enregistrée pour chaque utilisateur et reste active jusqu'à la déconnexion. Et si vous vous connectez à distance (par exemple, avec l'option ssh ), un login est enregistré pour cela. Chacun de ces éléments doit apparaître dans w La sortie de l'entreprise.
La plupart des applications de terminal, notamment Terminal.app et iTerm, ainsi que xterm si vous utilisez X11.app, sont capables de créer des coquilles de connexion dans une fenêtre ou un onglet. Lorsque vous créez une nouvelle fenêtre dans l'une de ces applications, vous pouvez obtenir une autre session de connexion, qui apparaît comme une autre ligne dans le fichier w . Mais ces applications ne nécessairement créer des coquilles de connexion ! Le fait qu'une nouvelle fenêtre/un nouvel onglet soit un shell de connexion est généralement contrôlé dans les préférences. Par exemple, dans iTerm2, vous pouvez choisir dans Préférences > Profils > Général > Commande de lancer un shell de connexion ou un autre programme. Si vous mettez simplement "bash" ici, vous obtiendrez un shell, mais ce ne sera pas un programme de type connexion coquille.
Alors quelle est la différence ? Elle est subtile, mais il est utile de la connaître.
Il y a une bonne discussion sur les coquilles de connexion par rapport aux coquilles normales ici : https://unix.stackexchange.com/questions/38175/difference-between-login-shell-and-non-login-shell . Mais nous pouvons résumer comme suit : un shell de connexion est lancé comme premier processus après que quelque chose ait établi une connexion en utmpx . Un shell non connecté peut être exécuté à tout moment par n'importe quel programme, mais il n'est pas le premier processus après une entrée dans le fichier utmpx . (Plus techniquement, un shell de connexion est le processus principal d'un groupe de processus. Le fait qu'il possède généralement un utmpx l'entrée est descriptive, pas nécessaire).
Si votre shell est bash comme la plupart le sont, chaque instance lit et exécute le programme d'action de l'UE. .bashrc dossier. Lorsque bash fonctionne comme un shell de connexion, il lit et exécute également le fichier .bash_profile y .profile fichiers. Ces fichiers peuvent contenir des instructions qui ne doivent se produire que pour toutes les nouvelles sessions. C'est la principale chose pratique à savoir sur les shells de connexion. Cela, et les shells de connexion apparaissent dans w .
Voici une expérience pour l'illustrer. Ouvrez une nouvelle fenêtre de Terminal, et exécutez w . Vous devriez voir quelque chose comme :
11:57 up 7 days, 59 mins, 5 users, load averages: 3.58 3.53 3.91
USER TTY FROM LOGIN@ IDLE WHAT
dgc console - 16Aug18 7days -
dgc s000 - 11:57 - w
s000 est le nom du terminal que vous exécutez w dans. Il existe sur le système de fichiers à /dev/ttys000 . En général, il y a une relation univoque entre les shells de connexion et les terminaux, mais pas toujours.
Ouvrez maintenant une nouvelle fenêtre Terminal. Revenez à la première, et exécutez w encore.
12:09 up 7 days, 1:11, 5 users, load averages: 5.35 4.35 4.05
USER TTY FROM LOGIN@ IDLE WHAT
dgc console - 16Aug18 7days -
dgc s000 - 11:38 - w
dgc s001 - 11:57 - -bash
Vous voyez un nouveau login sur s001 - /dev/ttys001 - qui est en cours d'exécution -bash . Ce trait d'union au début est une convention vous indiquant que bash s'exécute en tant que shell de connexion. Il n'y a pas de programme de premier plan dans ce terminal, donc w vous montre le shell lui-même.
Maintenant, revenez à votre deuxième fenêtre et exécutez bash . Que pensez-vous qu'il va se passer ?
12:13 up 7 days, 1:14, 5 users, load averages: 5.61 5.07 4.41
USER TTY FROM LOGIN@ IDLE WHAT
dgc console - 16Aug18 7days -
dgc s000 - 11:38 - w
dgc s001 - 11:57 - bash
Le trait d'union a disparu. C'est parce que la même session de connexion (terminal) exécute maintenant, au premier plan, un shell qui n'est pas un shell de connexion. Il s'agit d'un enfant de l'original -bash . Si vous revenez en arrière et tapez exit pour quitter le bash enfant, vous verrez l'icône -bash encore.
Enfin, notez le console connexion. Celui-ci ne changera jamais dans une utilisation ordinaire. C'est celui qui exécute le système de bureau/fenêtre habituellement. Si vous allumez votre Mac et Ne le fais pas. se connecter, mais ensuite vous ssh depuis un autre ordinateur, vous ne verrez pas du tout cette ligne. Elle apparaîtra toujours comme inactive, et semblera toujours ne rien exécuter - sauf avec le trait d'union, car il s'agit d'une session de connexion.
Lorsqu'un programme qui a créé une session de connexion met fin à cette connexion, il revient en arrière et supprime l'entrée de l'application utmpx en utilisant les méthodes de la bibliothèque commune. Et parce que utmpx réside dans le /var/run Ainsi, si vous avez soudainement éteint votre Mac alors que vous étiez connecté, vous ne continuerez pas à voir de fausses connexions à jamais.
