Wo wird die Standardeinstellung für die TERM-Umgebungsvariable festgelegt?


26

Wenn ich ein Terminalfenster mit dem GNOME-Terminalemulator in der Desktop-GUI öffne, wird die Umgebungsvariable TERM der Shell standardmäßig auf den Wert gesetzt xterm.

Wenn ich CTL+ ALT+ benutze F1, um zu einem Konsolen-TTY-Fenster zu wechseln und echo $TERMder Wert auf gesetzt ist linux.

Meine Motivation zu fragen ist, dass in meiner ~/.bashrcDatei eine Variable verwendet wird, um zu bestimmen, ob eine Farbschale bereitgestellt wird oder nur ein gutes altmodisches Monochrom.

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

Sowohl in der Konsolen-Shell als auch in der Gnome Terminal-Emulator-Shell, wenn ich tippe

export TERM=xterm-color
source /.bashrc

beide Muscheln wechseln in den Farbmodus (etwas, was ich mir immer in beiden gewünscht hätte).

Wo werden die Standardwerte TERMfestgelegt und wo können die Standardwerte am besten geändert werden, wenn dies überhaupt möglich ist? In der Benutzeroberfläche des Terminalemulators scheint es nichts zu geben, das den Standard-TERM-Wert auswählen oder festlegen könnte.

Ich habe überlegt, nur die Zeile export TERM=xterm-coloran den Anfang meiner ~/.bashrcDatei zu setzen, aber mein Bauchgefühl sagt, dass dies nicht die beste Lösung ist und meine Google-Suche mich noch nicht zu einer guten Antwort geführt hat.

Ich verwende Ubuntu 15.04 Desktop Edition (Debian-basiert).


Antworten:


17

An vielen Orten, je nachdem

Auf virtuellen Terminals und realen Terminals wird die TERMUmgebungsvariable von dem Programm festgelegt, mit dem die Verkettung erfolgt login, und wird bis zur interaktiven Shell vererbt, die nach der Anmeldung ausgeführt wird. Wo genau dies geschieht, hängt von System zu System und von der Art des Terminals ab.

Reale, serielle Anschlüsse können je nach dem, was sich am anderen Ende des Kabels befindet, vom Typ abweichen. Herkömmlicherweise wird das gettyProgramm mit einem Argument aufgerufen, das den Terminaltyp angibt, oder es wird das TERMProgramm von den Dienstkonfigurationsdaten eines Dienstmanagers übergeben.

  • Auf van Smoorenburg initSystemen kann man dies in /etc/inittabEinträgen sehen, die etwas in der Art von lesen

    S0: 3: Respawn: / sbin / agetty ttyS0 9600 vt100-nav
    Das letzte Argument agettyin dieser Zeile vt100-navist der Terminaltyp, für den festgelegt wurde /dev/ttyS0. So /etc/inittabist , wo für echte Terminals auf solchen Systemen den Terminaltyp zu ändern.
  • Auf systemd-Systemen kann man dies in der /usr/lib/systemd/system/serial-getty@.serviceUnit-Datei ( /lib/systemd/system/serial-getty@.serviceauf nicht zusammengeführten Systemen) sehen, die liest

    Umgebung = TERM = vt100
    Festlegen der TERMVariablen in der Umgebung, an die übergeben wird agetty. In dieser Service Unit-Datei können Sie den Terminaltyp für reale Terminals auf solchen Systemen ändern. Beachten Sie, dass dies für alle realen Terminals gilt, die diese Service-Unit-Vorlage verwenden. (Um es nur für einzelne Terminals zu ändern, muss die Vorlage manuell instanziiert werden.)
  • Nimmt auf den BSDs initden Terminaltyp aus dem dritten Feld des Eintrags jedes Terminals in der /etc/ttysDatenbank und legt TERMdiesen in der Umgebung fest, mit der es ausgeführt wird getty. So /etc/ttysist , wo man den Terminaltyp für reale Anschlüsse an den BSDs ändert.

Wie Sie bereits bemerkt haben, haben virtuelle Kernel-Terminals einen festen Typ. Im Gegensatz zu NetBSD, das den virtuellen Terminaltyp des Kernels im laufenden Betrieb variieren kann, verfügen Linux und die anderen BSDs über einen einzigen festen Terminaltyp, der im integrierten Terminalemulationsprogramm des Kernels implementiert ist. Unter Linux stimmt dieser Typ mit linuxder terminfo-Datenbank überein . (Die Kernel-Terminal-Emulation von FreeBSD ist xtermseit Version 9 eine eingeschränkte Untermenge.)

  • Auf Systemen, die mingettyoder vc-get-tty(aus dem nosh-Paket) verwenden, "weiß" das Programm, dass nur mit einem virtuellen Terminal gesprochen werden kann, und sie verdrahten die "bekannten" virtuellen Terminaltypen, die dem Betriebssystem entsprechen, für das das Programm kompiliert wurde.
  • Auf systemd-Systemen kann man dies in der /usr/lib/systemd/system/getty@.serviceUnit-Datei ( /lib/systemd/system/getty@.serviceauf nicht zusammengeführten Systemen) sehen, die liest

    Umgebung = TERM = Linux
    Festlegen der TERMVariablen in der Umgebung, an die übergeben wird agetty.

Für virtuelles Kernel - Terminals, eine nicht den Terminaltyp verändern. Das Terminal-Emulator-Programm im Kernel ändert sich schließlich nicht. Es ist falsch , den Typ zu ändern. Dies wird insbesondere die Erkennung von Cursor- / Bearbeitungstasten-CSI-Sequenzen vermasseln. Die linuxCSI - Sequenzen durch den Terminal - Emulator Linux - Kernel gesendet werden , anders als die xtermoder vt100CSI - Sequenzen von GUI - Terminal - Emulator Programmen in Dezember VT - Modus gesendet.

Ihr GUI-Terminal-Emulator ist eines von vielen Programmen, von SSH bis hin zu screenPseudo-Terminals. Der Terminaltyp hängt davon ab, welches Terminalemulatorprogramm auf der Masterseite des Pseudoterminals ausgeführt wird und wie es konfiguriert ist. Die meisten GUI-Terminalemulatoren starten das Programm auf der Slave-Seite mit einer TERMVariablen, deren Wert mit ihrer Terminalemulation auf der Master-Seite übereinstimmt. Programme wie der SSH-Server versuchen, den Terminaltyp auf dem Client-Ende der Verbindung zu "passieren". Normalerweise gibt es ein Menü oder eine Konfigurationsoption, um zwischen Terminalemulationen zu wählen.

Die packende Hand

Die richtige Methode zum Erkennen der Farbfähigkeit besteht nicht darin , eine Liste der Terminaltypen in Ihrem Skript festzuklemmen. Es gibt sehr viele Terminaltypen, die Farben unterstützen.

Der richtige Weg ist, sich anzusehen, was termcap / terminfo über Ihren Terminaltyp aussagt.

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

Weitere Lektüre

  • Jonathan de Boyne Pollard (2018). TERM. nosh Führer . Software.

Im Folgenden gibt es in dem Standard Bashrc in Debian jessie: [ -x /usr/bin/tput ] && /usr/bin/tput setaf 1 >&/dev/null && color_prompt=yes. (ncurses 5.9)
thom_nic

2
Auch tput Cogibt „unbekannt term capability“ in Jessie und Xenial. tput colorsund tput setaf 1beide scheinen zu funktionieren, obwohl ich zugebe, ich verstehe nicht warum .
thom_nic

2

Unter https://askubuntu.com/a/614714/398785 finden Sie eine ausführliche Antwort darauf, warum ich TERM=xterm-colorden falschen Ansatz halte und Ubuntus .bashrcobsolet ist. Ich empfehle, dass Sie mit gehen TERM=xterm-256color(was die Standardeinstellung seit Gnome-Terminal 3.16 ist, aber auch sicher mit älteren Gnome-Terminals zu verwenden ist) und Ihr .bashrcentsprechend anpassen .


1
+1 für deinen Link. Kleiner Vorschlag; Der folgende Satz könnte verwirrend sein (ich hatte zuerst den Eindruck, dass Sie sagten, die Verwendung .bashrcsei obsolet). "Ubuntus .bashrc ist veraltet."
IsaacS

@IsaacS Haben Sie Vorschläge, wie Sie es verbessern können? Würde zB das Ersetzen von "veraltet" durch "veraltet" helfen?
egmont

1
Es scheint , dass xterm-256colorUrsachen htopzu vermasseln das Layout wie dies in Ubuntu 18.04.
Hör auf, Monica

@OrangeDog In welchem ​​Terminalemulator? Diese Frage hier und damit meine Antwort konzentriert sich auf GNOME Terminal, während die Seite, die Sie verlinkt haben, Konsole zeigt. Der Fehler sieht so aus, als ob der Terminal-Emulator die REP-Escape-Sequenz, die ncurses zu dieser Zeit verwendet hat, noch nicht unterstützt. VTE (GNOME Terminal) hatte bereits in Ubuntu 18.04 Unterstützung hinzugefügt, wahrscheinlich hatte Konsole dies nicht. Ich vermute, dass Ihr Kommentar mit dem htop-Fehler für Konsole, aber nicht für GNOME Terminal gültig ist.
Egmont

@egmont kann nicht für das ursprüngliche Problem sprechen, aber ich erhalte das gleiche Ergebnis mit dem WSL-Terminal (was auch immer das ist).
Hör auf, Monica
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.