Le mécanisme
Ce que le panneau lance vraiment, et ce qui se passe ensuite.
Un pseudo-terminal exécutant votre shell de connexion, avec un environnement assemblé délibérément plutôt qu’hérité en bloc — et une réponse définie au moment où une commande qu’on y tape change le fichier au-dessus.
01Il démarre dans le dossier du fichier
Le répertoire de travail est celui du fichier de l’onglet, pas la racine du projet. Si ce dossier a disparu, il se rabat sur le dossier ouvert, puis sur votre répertoire personnel. Deux onglets portant des fichiers dans des dossiers différents donnent deux shells à des endroits différents.
02Ou il appartient à un dossier de l’espace de travail
Un terminal peut être lancé pour l’une des racines de l’espace de travail plutôt que pour un fichier, ce qui est le shell qu’on veut pour une compilation ou une série de tests. Le panneau demande ce que vous vouliez dire quand le choix est réel, et permet de passer d’un shell déjà lancé à l’autre.
03L’épinglage garde un shell au-delà de son onglet
Un terminal de fichier se termine avec son onglet, sauf si vous l’épinglez. Un shell épinglé continue de tourner, et rouvrir ce fichier le récupère plutôt que d’en lancer un second. Un terminal de projet est épinglé par définition.
04Le panneau se divise en trois shells au maximum
Terminal ▸ Diviser le terminal (⌃⇧5) divise le panneau en colonnes comme l’éditeur se divise en volets. Une division est un second shell sur le même lien — même fichier, même épinglage, terminé par le même onglet — lancé dans le répertoire où se trouve à cet instant le shell dont il est issu, c’est-à-dire en général le dossier où vous venez d’aller.
05Un onglet propre se recharge, en silence
Lancez un formateur et l’onglet se met à jour. Il ne demande pas, délibérément : dès lors qu’un terminal peut écrire dans ces fichiers, une confirmation par fichier voudrait dire une avalanche de fenêtres pour une commande que vous venez de taper vous-même.
06Un onglet avec des modifications non enregistrées n’est jamais écrasé
Il demande — « modifié sur le disque. Cet onglet a des modifications non enregistrées. Recharger et les abandonner ? » — avec Recharger et Garder les miennes. Choisir Garder les miennes avance la date de modification enregistrée, pour qu’il ne redemande pas au sujet du même changement.
07Votre shell de connexion, avec -l
Le shell est lancé comme shell de connexion, pour que ~/.zprofile et consorts soient lus. Les outils installés par Homebrew ou un gestionnaire de versions sont dans le PATH parce que le shell l’a configuré comme il le fait toujours.
08TERM et COLORTERM sont correctement posés
TERM vaut xterm-256color et COLORTERM vaut truecolor, pour que les programmes qui vérifient avant d’émettre de la couleur 24 bits en émettent réellement.
09TERM_PROGRAM dit Linelark
C’est la variable que les outils lisent pour savoir dans quel terminal ils se trouvent, et y répondre honnêtement est la façon dont ils s’adaptent correctement.
10Linelark_FILE nomme le fichier au premier plan
Le répertoire de travail n’a jamais dit que le dossier. Ceci dit quel fichier, ce qu’un outil en ligne de commande veut généralement savoir.
11Elle est posée ou retirée, jamais héritée
L’app peut elle-même être lancée depuis un de ces shells. Sans l’effacer, un onglet sans titre hériterait d’une valeur périmée et se prétendrait le fichier de quelqu’un d’autre.
12Les fuites de débogage sont retirées
OS_ACTIVITY_DT_MODE et consorts sont retirés de l’environnement de l’enfant, sans quoi les programmes lancés depuis une compilation de développement croient qu’on les débogue.