Lorsque j'ouvre une fenêtre de terminal avec l'émulateur de terminal GNOME dans l'interface graphique du bureau, la variable d'environnement TERM du shell prend par défaut la valeur xterm .

Si j'utilise CTL +ALT +F1 pour passer à une fenêtre TTY de console et echo $TERM la valeur est définie sur linux .

Ma motivation pour demander est que dans mon ~/.bashrc fichier une variable est utilisée pour déterminer si une coque de couleur est fournie ou juste un bon monochrome à l'ancienne.

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color) color_prompt=yes;;
esac

Dans le shell de la console et le shell de l'émulateur Gnome Terminal si je tape

export TERM=xterm-color
source /.bashrc

les deux coques passent en mode couleur (quelque chose que j'aimerais que cela se produise toujours dans les deux).

D'où vient le TERM par défaut les valeurs sont définies s'il vous plaît et où est le meilleur endroit pour modifier leurs valeurs par défaut, si possible ? Il semble qu'il n'y ait rien dans l'interface graphique de l'émulateur de terminal pour sélectionner ou définir la valeur TERM par défaut.

J'ai simplement envisagé d'ajouter la ligne export TERM=xterm-color en haut de mon ~/.bashrc fichier mais mon instinct me dit que ce n'est pas la meilleure solution et mes recherches sur Google ne m'ont pas encore conduit à une bonne réponse.

J'utilise Ubuntu 15.04 Desktop Edition (basé sur Debian).

Réponse acceptée :

Dans de nombreux endroits, selon

Sur les terminaux virtuels et les terminaux réels, le TERM la variable d'environnement est définie par le programme qui s'enchaîne à login , et est hérité tout le long du shell interactif qui s'exécute une fois que l'on s'est connecté. L'endroit précis où cela se produit varie d'un système à l'autre et selon le type de terminal.

terminaux réels

Les terminaux réels, en série, peuvent varier en type, selon ce qui se trouve à l'autre extrémité du fil. Donc classiquement le getty le programme est appelé avec un argument qui spécifie le type de terminal, ou reçoit le TERM programme à partir des données de configuration de service d'un gestionnaire de services.

• Sur van Smoorenburg init systèmes, on peut le voir dans /etc/inittab entrées, qui liront quelque chose dans le sens de

  S0:3:respawn:/sbin/agetty ttyS0 9600 vt100-nav

  Le dernier argument de agetty dans cette ligne, vt100-nav , est le type de terminal défini pour /dev/ttyS0 . Donc /etc/inittab est l'endroit où changer le type de terminal pour les terminaux réels sur de tels systèmes.

• Sur les systèmes systemd, on pouvait voir ceci dans le /usr/lib/systemd/system/[email protected] fichier d'unité (/lib/systemd/system/[email protected] sur les systèmes non fusionnés), qui lisaient

  Environment=TERM=vt100

  définir le TERM variable dans l'environnement passée à agetty .

• Sur les BSD, init prend le type de terminal du troisième champ de l'entrée de chaque terminal dans /etc/ttys base de données et définit TERM à partir de cela dans l'environnement qu'il exécute getty avec. Donc /etc/ttys est l'endroit où l'on change le type de terminal pour les vrais terminaux sur les BSD.

variabilité de systemd

Le [email protected] Le fichier d'unité de service, ou les fichiers d'insertion qui s'y appliquent, est l'endroit où changer le type de terminal pour les terminaux réels sur les systèmes systemd. Notez qu'un tel changement s'applique à tous les services de connexion au terminal qui utilisent ce modèle d'unité de service. (Pour le changer uniquement pour des terminaux individuels, il faut instancier manuellement le modèle ou ajouter des drop-ins qui ne s'appliquent qu'aux instanciations.)

systemd a eu au moins quatre mécanismes au cours de sa vie pour récupérer la valeur du TERM variables d'environnement. Au moment de la première rédaction de cette réponse, comme on peut le voir, il y avait un Environment=TERM=something ligne dans les fichiers modèles d'unité de service. À d'autres moments, les types linux et vt102 étaient câblés dans le getty et serial-getty fichiers d'unité de service respectivement. Plus récemment, la variable d'environnement a été héritée du processus 1, qui l'a définie de différentes manières.

À partir de 2020, la façon dont systemd décide du type de terminal à spécifier dans le TERM d'un service La variable d'environnement est assez complexe et n'est pas documentée du tout. La façon de le changer reste un fichier de configuration avec Environment=TERM=something . Mais d'où provient la valeur par défaut est assez variable. Sous réserve de certaines règles assez complexes à expliquer qui impliquent le TTYPath= paramètres des unités de service individuelles, il peut s'agir de l'une des trois valeurs suivantes :un linux câblé , un vt220 câblé (n'est plus vt102 ), ou la valeur du TERM variable d'environnement dont le processus #1 a hérité, généralement du chargeur noyau/bootstrap.

(Ironiquement, le getttyent() existe toujours dans la bibliothèque GNU C, et systemd aurait pu réutiliser le /etc/ttys mécanisme.)

terminaux virtuels du noyau

Les terminaux virtuels du noyau, comme vous l'avez noté, ont un type fixe. Contrairement à NetBSD, qui peut faire varier le type de terminal virtuel du noyau à la volée, Linux et les autres BSD ont un seul type de terminal fixe implémenté dans le programme d'émulation de terminal intégré du noyau. Sous Linux, ce type correspond à linux de la base de données terminfo. (L'émulation de terminal du noyau de FreeBSD depuis la version 9 est teken . Avant la version 9, c'était cons25 OpenBSD est pccon .)

• Sur les systèmes utilisant mingetty ou vc-get-tty (à partir du paquet nosh) le programme "sait" qu'il ne peut parler qu'à un terminal virtuel, et ils câblent les types de terminaux virtuels "connus" appropriés au système d'exploitation pour lequel le programme a été compilé.
• Sur les systèmes systemd, on pouvait voir ceci dans le /usr/lib/systemd/system/[email protected] fichier d'unité (/lib/systemd/system/[email protected] sur les systèmes non fusionnés), qui lisent

  Environment=TERM=linux

  définir le TERM variable dans l'environnement passée à agetty .

Pour les terminaux virtuels du noyau, on ne le fait pas changer le type de borne. Le programme d'émulation de terminal dans le noyau ne change pas, après tout. C'est incorrect pour changer de type. En particulier, cela bousillera la reconnaissance de la séquence CSI du curseur/touche d'édition. Le linux Les séquences CSI envoyées par l'émulateur de terminal du noyau Linux sont différentes du xterm ou vt100 Séquences CSI envoyées par les programmes d'émulation de terminal GUI en mode DEC VT. (En fait, ils sont très idiosyncratiques et non standard, et différents à la fois de tous les terminaux réels que je connais et de pratiquement tous les autres émulateurs de terminaux logiciels à l'exception de celui intégré à Linux.)

Émulateurs de terminaux graphiques

Votre émulateur de terminal GUI est l'un des nombreux programmes, du dæmon SSH à screen , qui utilise des pseudo-terminaux. Le type de terminal dépend du programme d'émulation de terminal qui s'exécute du côté maître du pseudo-terminal et de la manière dont il est configuré. La plupart des émulateurs de terminaux GUI démarreront le programme du côté esclave avec un TERM variable dont la valeur correspond à leur émulation de terminal côté maître. Des programmes tels que le serveur SSH tenteront de "transférer" le type de terminal qui se trouve du côté client de la connexion. Il existe généralement un menu ou une option de configuration à choisir parmi les émulations de terminal.

La main agrippante

La bonne façon de détecter la capacité de couleur n'est pas pour câbler une liste de types de terminaux dans votre script. Il existe énormément de types de terminaux prenant en charge la couleur.

La bonne façon est de regarder ce que dit termcap/terminfo à propos de votre type de terminal.

colour=0
if tput Co > /dev/null 2>&1
then
    test "`tput Co`" -gt 2 && colour=1
elif tput colors > /dev/null 2>&1
then
    test "`tput colors`" -gt 2 && colour=1
fi

Autres lectures

• Jonathan de Boyne Pollard (2018). TERM . Guide bouffe . Logiciels.