GNOME Bugzilla – Bug 115750
TERM environment variable could be better
Last modified: 2015-06-14 08:35:03 UTC
gnome-terminal sets the environment variable TERM to "xterm". It should possibly use "xterm-color", so that termcap applications (in my case vim) use colored output. Note: Debian (and possibly Redhat, too) define the xterm stuff to support color, so it works there. NCurses 5.3 built from source does not however.
I really don't know what the good thing is here, though, because there are quite a lot of variants of xterm. Maybe Nalin knows?
AFAIK the termcap database isn't guaranteed to have aything in it (not even "xterm" now that I think about it), and its contents are almost certain to be different from OS to OS or from distribution to distribution. For a while, the Fedora development tree matched the ncurses 5.4 source, but it was reluctantly reverted when the bug reporter's problem cropped up, and it will probably be revisited again. The Debian folks seem to want to tough it out. I guess for now we'll make it a compile-time default in the vte module (in HEAD). Long-term, if/when the support for other terminal types actually becomes correct enough to be usable, it could conceivably become a run-time option, but we're not there.
James Vega simply suggested in Debian bug http://bugs.debian.org/368916 to use TERM=gnome. Perhaps "vte" would be even better. From my PoV, working around termcap DB limitations is the distributors problem as he is the only one to know what the DB of the target OS contains, and the closest thing he should pick for gnome-terminal / vte. The configure time option is a nice override, but it would be best to standardize the default to something obvious such as "gnome" or "vte".
TERM=gnome seems to work fine here, but TERM=vte makes various applications err and not run: [behdad@home termcaps]$ ssh cs Last login: Thu Jun 8 11:37:24 2006 from nat-pool-yyz.redhat.com unknown terminal "vte" unknown terminal "vte" [behdad@epoch behdad]$ pine Terminal type "vte", is unknown.
Yes, AIUI ncurses has terminfo entries for "gnome", added (I think) back when gnome-terminal used libzvt. For this reason I agree that "vte" is a better choice since the term capabilities are implemented by the widget, not the application. A future emulation widget might implement a differnt set of capabilities that don't match the existing "gnome" term.
And what do you exactly suggest to do with all those ncurses applications that don't work with TERM=vte?! No thanks.
Forgive me if I've misunderstood you... We don't need to modify the applications, can't we just add vte to ncurses' terminfo database? (ie. make a copy of /usr/share/terminfo/g/gnome in /usr/share/terminfo/v/vte). Even as a non-root user, you can copy /usr/share/terminfo/g/gnome to ~/.terminfo/v/vte and ncurses will now support TERM=vte. Ideally we get the new term added to upstream ncurses, but failing that distros/packagers can make sure it is present. The benefit of using TERM=gnome is that it already exists in the current ncurses db. The risk I see is that GNOME's already gone through 2 different term widgets (zvt and vte) implementing different capabilities, a future widget might implement a different terminal again. They shouldn't use TERM=gnome if they don't actually match each other. The other option is to actually implement all the control sequences supported by xterm, so that TERM=xterm is actually appropriate. But it doesn't seem like that's really on the agenda. (For more context on this, see http://bugs.debian.org/363576).
The problem is not easily solved locally. If TERM is set to vte, I have to go copy that terminfo thing in every (possibly legacy) Unix system I ever want to ssh to. I don't think there's much we will gain here.
Yep, but the same will be true for TERM=gnome, so it has little real advantage in this regard... the issue in the Debian bug I referenced above happens because vte claims to be an xterm but vim uses xterm control sequences that vte doesn't actually support.
You can always export TERM to workaround old termcap databases, like I sometimes do when I export TERM=vt100. If you don't differenciate vte via TERM, the termcap databases won't ever include data either. :-/
The proper resolution here is to first push termcap entries for "vte" into common databases first, and switch after a few years that it's widespread, like "gnome" is now. As for not handling xterm sequences properly, that's a separate bug that should be fixed.
I don't believe common databases will include any information if the terminal isn't used in real life yet, even if it would be less painful.
In that case, how has the TERM=gnome propagated? If vte sets TERM=vte, *I* get the bug reports, not you. No, Thanks!
How it propagated? Pretty badly: bee% LC_ALL=C TERM=gnome vim zsh: can't find terminal definition for gnome E558: Terminal entry not found in terminfo 'gnome' not known. Available builtin terminals are: builtin_gui builtin_riscos builtin_amiga builtin_beos-ansi builtin_ansi builtin_pcansi builtin_win32 builtin_vt320 builtin_vt52 builtin_xterm builtin_iris-ansi builtin_debug builtin_dumb defaulting to 'ansi' It's your call, perhaps you want to introduce it progressively such as with a configure flag defaulting to xterm for now, and advertizing the fact you will change it to "vte".
Ok, anybody has a terminfo entry for vte? And also we need somebody (that can decrypt terminfo) willing to maintain it.
Created attachment 67211 [details] Sample terminfo for the xterm flavors in Debian This terminfo file builds the whole xterm variants (via tic) we use in Debian. It's at least DFSG free, but I don't know if it's 100% LGPL compatible. I don't know anything about implementation of terminfo files, but if you're interested in reusing the file, I can try contacting the various authors via the Debian changelog.
Most terminal emulators provide a way for the user to specify what the TERM environment variable should be set to, e.g., term in screen and *termName in xterm. Why not provide this as a command-line switch or profile setting in gnome-terminal?
Hello, There has been a 'gnome' entry in upstream ncurses terminfo since a long time, and thus you should be able to switch to this without bigger problems. Having and using a 'vte' terminfo is not a solution as all terminals that use vte do not behave the same way. That said, 'xterm' as $TERM in gnome-terminal is plain incorrect.
On the other hand, it would actually be nice if vte would set $TERM to 'gnome' by default, then let the terminal override it if it wishes to.
Alternatively, why not fix whatever makes gnome-terminal and vte not xterm compatible, and leave TERM=xterm?
That's pretty much my current state of thought. Problem with that seems to be that we support more than xterm.
Regarding comment #21: do you have a document somewhere listing the things vte supports, similar to xterm's ctlseqs document (http://invisible-island.net/xterm/ctlseqs/ctlseqs.html)?
Not really.
Lemme clarify though: we don't support any ctlseqs of our own. We support multiple charsets, etc, and in general some extra features not relevant to ctlseqs, but in how they are implemented. I'm hand waving. The best course of action is to close this bug and open new ones for each individual case we do not act like xterm. I've fixed many many bugs like that.
I think there's no way around making this configurable. As a previous poster mentioned, the correct value is dependent on the intersection of the capabilities of gnome-terminal AND the installed termcap entries. For instance if I want to use 256 colors, the correct TERM value is xterm-256color but there has to be a termcap entry for it, which gnome-terminal by itself cannot know (you could later ssh to another machine with a different set of installed termcap entries). So I really would like the value of TERM to be configurable on a per-profile basis, perhaps with a drop-down menu of possible entries so people won't set it to an incompatible value.
Created attachment 160162 [details] [review] Add gconf key 'termname' to set $TERM (In reply to comment #25) > I think there's no way around making this configurable. > As a previous poster mentioned, the correct value is dependent on the > intersection of the capabilities of gnome-terminal AND the installed termcap > entries. I agree. The attached patch adds a gconf key to configure termname.
There should UI be added for this under the "Compatibility" tab of the Profile Preferences dialog also, and cmdline arguments. It's a lot of wiring really. See any of my recent commits for all the various places a new profile option needs to be hooked up.
Created attachment 160167 [details] [review] Add gconf key 'termname' to set $TERM And now it actually builds :). Sorry about the spam.
Created attachment 165220 [details] [review] Add termname profile option to set $TERM. (In reply to comment #27) > There should UI be added for this under the "Compatibility" tab of the Profile > Preferences dialog also, and cmdline arguments. It's a lot of wiring really. > See any of my recent commits for all the various places a new profile option > needs to be hooked up. Added UI, but not cmdline arguments, because it seems most per-profile options don't have those either. --termname is already handled with unsupported_option_callback.
Humm, master is ported to gsettings I guess? ChPe, how do you want to see this bug progress?
Master isn't ported to gsettings yet (waiting for gsettingslist), so, IF we want this feature, let's either add it right now, since otherwise the patch will just be completely obsolete.
The feature is definitely desirable. I don't have time right now to review it right now though. Can you?
I don't really have time either. A question: what about vte_terminal_set_emulation(), should that be used in conjunction with the env variable? Will there be problems if emulation stays on "xterm" but the env var say something else?
Donno. That's definitely something that we need to figure out first.
Now that 256 color in 2011 is a lot better, it would be nice if we were to set TERM=xterm-256color. Other systems (e.g. OS X Lion) already do this by default. The right solution would probably be to commit either Lauri's patch, albeit modified to use xterm-256color, or simply add a checkbox to the GUI to toggle between TERM=xterm and TERM=xterm-256color.
(In reply to comment #35) > Now that 256 color in 2011 is a lot better, it would be nice if we were to set > TERM=xterm-256color. Other systems (e.g. OS X Lion) already do this by default. I don't think that's a sensible default. If you connect to remote systems (eg. via ssh), xterm is virtually guaranteed to work, but older systems might not have xterm-256color terminfo. Do we want to break compatibility with those systems? That said, I do set TERM=xterm-256color personally, but it should be a conscious choice by the user.
Well, it doesn't harm to be a bit more progressive here. The xterm-256color entry seems to be introduced in the terminfo db between ncurses version 5.0 and 5.1 (thus somewhere between October 1999 and July 2000). If we really care about compatibility, we shouldn't be using UTF-8 by default either.
Related news: Fedora 18 will use xterm-256color for TERM [1]. They are doing it via /etc/profile: if TERM=xterm then change it to TERM=xterm-256color. This is probably not the best way to enable 256 colors. It would have been better if the terminal itself sets the correct value. I am afraid that if this issue is not addressed then others will follow fedora's example and implement similar partial solutions. [1] https://fedoraproject.org/w/index.php?title=Features/256_Color_Terminals&oldid=295783
Re comment 38: I find it curious that this wasn't discussed with upstream first but instead is being done downstream...
(In reply to comment #39) > Re comment 38: I find it curious that this wasn't discussed with upstream first > but instead is being done downstream... What would you think could be upstreamed? They changed it in /etc/profile. That's a file they maintain themselves. But still, if it takes more than 9 years to get this fixed in GNOME Terminal, I can imagine that distros will eventually do things like patching /etc/profile. It's 2012. GNOME Terminal should just use TERM=xterm-256color.
So the biggest problem seems to be the lack of - a standard - communication between terminal developers and application developers which leads to flamefests in blogs and elsewhere when someone uses gnome-terminal to ssh into the corporate IRIX machine running a statically linked ncurses management tool from 1997 that suddenly doesn't work anymore. If there was a clear message from all sides that TERM=xterm-256color is the right thing to use and people accessing those machines should change the TERM in ~/.profile I don't think anybody would mind changing it here. Same thing about everybody agreeing that TERM=xterm implies color support and telling people to set TERM=ansi in terminal emulators that don't. People just need to agree on something instead of some distros pathing emulators, some distros patching /etc/profile and people doing flamefests (in bug reports for now).
I still think this should be configurable to cover all use cases. TERM is a property of the terminal, not the shell, so I think it should be set by the terminal. One can also start processes in the terminal without running the shell (using the -e command line option), in which case shell startup files don't even get sourced. I've been using xterm-256color for a couple of years now, and it's not without problems. Even newly installed Solaris 11 systems (in June 2012!) do not work with xterm-256color by default (although the terminfo seems to be present, it's just not in a place that is searched by default). However, I don't think this is really about whether the default should be xterm or xterm-256color, distros can make that decision for all I care if this becomes a configurable terminal setting. But if this is *not* configurable, anything other than xterm will cause regressions.
(In reply to comment #42) > I've been using xterm-256color for a couple of years now, and it's not without > problems. Even newly installed Solaris 11 systems (in June 2012!) do not work Could you expand on the issues? If we have a list we could make a better decision. We can also reach out to get the issues fixed.
(In reply to comment #43) > Could you expand on the issues? If we have a list we could make a better > decision. We can also reach out to get the issues fixed. The cause for all the issues I have is really that all the systems I connect to do not have the xterm-256color terminfo (or at least not in the correct place to be found automagically). This is mostly curses application breakage (eg. 'less' whines that the terminal is not fully functional and becomes considerably less pleasant to use).
It has already been pointed out in this thread that the only proper solution is to make TERM configurable (per-profile and with a reasonable default value). I'm not sure what else remains to discuss, except if somebody successfully demonstrates that making it configurable isn't the way to go (while explaining how their solution solves the problem of SSHing from machine A to machine B when both machines have different, arbitrary installed termcaps). Again, the correct value can only be dynamically determined, and hence should be configurable. Switching the current constant value to whatever other constant isn't going to fix it.
(In reply to comment #45) > It has already been pointed out in this thread that the only proper solution is > to make TERM configurable (per-profile and with a reasonable default value). I'm not against a configuration option. But a configuration option is still a terrible solution. If I work in a shell I might connect to various systems. I don't want to switch to a new profile or new tab just because some remote system doesn't understand the TERM environment variable. Short term a configuration option is a good workaround. But at the same time these systems (default installation) have to be updated to support the new TERM setting.
(In reply to comment #46) > (In reply to comment #45) > > It has already been pointed out in this thread that the only proper solution is > > to make TERM configurable (per-profile and with a reasonable default value). > > I'm not against a configuration option. But a configuration option is still a > terrible solution. > It's the only one that works in all cases. > If I work in a shell I might connect to various systems. I don't want to switch > to a new profile or new tab just because some remote system doesn't understand > the TERM environment variable. > Fine, then you'll have to set it manually, or just deal with a broken/half-functional terminal. If you think it's a superior user experience compared to having the possibility of configuring in the profile, I don't. > Short term a configuration option is a good workaround. But at the same time > these systems (default installation) have to be updated to support the new TERM > setting. If the default value for the configurable option is the same as the current one, you won't be forced to change anything, but will have the option to.
(In reply to comment #46) >If I work in a shell I might connect to various systems. I don't want to switch >to a new profile or new tab just because some remote system doesn't understand >the TERM environment variable. I agree, this is why the current default of 'xterm' should be kept. If distros want to change the default, then fine: there's the configuration option. > Short term a configuration option is a good workaround. But at the same time > these systems (default installation) have to be updated to support the new TERM > setting. Yeah, sure, but that's not a problem that the terminal emulator can really solve.
I don't think a configuration option is necessary. There is literally hundreds of ways you can reconfigure the TERM variable already - including the one that Fedora chose.
(In reply to comment #49) > I don't think a configuration option is necessary. There is literally hundreds > of ways you can reconfigure the TERM variable already - including the one that > Fedora chose. That is a terrible way to do it. The environment variable describes the capabilities of the terminal, therefore the terminal should be the only thing that sets it. Also see my comment #42 regarding programs other than the shell.
(In reply to comment #47) > > I'm not against a configuration option. But a configuration option is still a > > terrible solution. [..] > Fine, then you'll have to set it manually, or just deal with a > broken/half-functional terminal. If you think it's a superior user experience > compared to having the possibility of configuring in the profile, I don't. Do you have some wish to get upset with me?!? Suggest to re-read what I said.
(In reply to comment #50) > That is a terrible way to do it. The environment variable describes the > capabilities of the terminal, therefore the terminal should be the only thing > that sets it. > If it describes the capabilities of the terminal, it shouldn't be configurable. It should automatically be set based on the capabilities of the terminal.
(In reply to comment #52) > (In reply to comment #50) >> That is a terrible way to do it. The environment variable describes the >> capabilities of the terminal, therefore the terminal should be the only thing >> that sets it. > If it describes the capabilities of the terminal, it shouldn't be configurable. > It should automatically be set based on the capabilities of the terminal. Maybe in an ideal world. But the current situation is that: - either the terminal gives its *full* capabilities (e.g. xterm-256color), but some systems don't know the "xterm-256-color" moniker and fallback to dumb terminal. ====> FAIL - or the terminal lies on its capabilities by saying it supports less than it does (e.g. "xterm"), and systems that *are* able to use its whole abilities don't make use of the whole abilities. ====> FAIL One might hope that telnet/ssh/... would automatically "downgrade" xterm-256color to xterm when logging in from a system that knows xterm-256color to one that does not, but the current situation is *also* that they don't. So frankly, making it configurable may be a cop-out, but it is the only situation where *each* user can be moderately happy, depending on his/her situation.
Which goes back to comment 49 - there's already lots of ways to configure TERM if you want to change it.
(In reply to comment #52) > If it describes the capabilities of the terminal, it shouldn't be configurable. > It should automatically be set based on the capabilities of the terminal. That's a good point, but due to the way that information is conveyed (assume the remote system knows about this terminal; Lionel described the situation well in comment 53), the mentioned compatibility issues are observed. The user should be able to decide whether to remain compatible or not. (In reply to comment #54) > Which goes back to comment 49 - there's already lots of ways to configure TERM > if you want to change it. Which, in turn, goes back to comment 42 :-) If you agree that TERM needs to be configurable and that it is a property of the terminal, I don't see how you can say child processes should decide for themselves which value to use (and they wouldn't know what terminal they're running in anyway unless you communicate that somehow).
A co-worker of mine runs 'tput cols' and checks the exit status, as a means of iteratively trying a number of TERM settings until one makes sense.
(In reply to comment #49) > I don't think a configuration option is necessary. There is literally hundreds > of ways you can reconfigure the TERM variable already - including the one that > Fedora chose. It’s difficult to reconfigure TERM in a way that doesn’t affect other terminal emulators, which may or may not support 256 colors. Fedora’s solution checks for the COLORTERM environment variable, which is set by gnome-terminal, but is also present in the environment of other terminal emulators launched from gnome-terminal (or launched from applications launched from gnome-terminal, etc.).
gnome-terminal no longer sets COLORTERM starting with 3.13.0 (commit 1d5c1b6ca6373c1301494edbc9e43c3e6a9c9aaf) so I guess Fedora's solution is broken now. If only TERM supported fallbacks (e.g. TERM=xterm-256color:xterm, meaning if one setting is not present in terminfo fall back to the 2nd etc.), this could be solved nicely...
The default was recently changed to TERM=xterm-256color (bug 740641).
Which doesn't really solve things... it still breaks all kinds of applications and terminfo, since gnome-terminal *is not* XTerm, neither is it compatible. See also http://invisible-island.net/ncurses/ncurses.faq.html#xterm_generic
There are a numerous problems with $TERM per se. It's by design a legacy crap. Not even xterm itself complies to TERM=xterm, e.g. see the Home/End keys, let alone termcap/terminfo can't describe application keypad mode and similar ones. The definition needs to be deployed to every host you might log in to, including those that are like 5 or 10 years old or even older, also commercial Unix variants, good luck convincing all the vendors to ship a vte-specific terminal description, and even if they do, they'll likely lag behind by a few years. It's not versionable, e.g. xterm recently introduced support for italic text and added the corresponding capability, yet there's no way to guarantee that a pre-italic xterm matches with a pre-italic xterm terminfo definition, and a post-italic matches a post-italic. Vte also regularly changes/fixes some emulation issue or adds a new feature. The terminfo only describes a small subset of the terminal's features. Not a single word about e.g. which OSC sequences are supported, what sequences are generated in application keypad mode, how the modifiers are encoded. No possibilities to add custom extensions. Probably the correct solution would have been to have $TERMCAP which fully describes the capabilities, and is forwarded over ssh. The current terminfo database would only be used to initialize $TERMCAP when you log in from a physical terminal. But that's now what this area evolved to. There's no point in aiming for perfectness in a world when it can't be achieved. Then you can only aim for "good enough", and for that xterm(-256colors) is IMO a very good choice. By the way, konsole and terminology also chose this path. The page you linked is 3+ years old; vte has since then fixed plenty of bugs and made the emulation much better and much closer to xterm's. If there's a specific issue, let's discuss that separately. As for $TERM, I think xterm-256colors is currently the most reasonable compromise.
s/now/not/
(In reply to Egmont Koblinger from comment #61) > There are a numerous problems with $TERM per se. Which? And it doesn't have the problems of e.g. $SHELL. > It's by design a legacy crap. It still seems to be *the* way for terminfo to know which terminal runs... so legacy or not, it's still massively used. > Not even xterm itself complies to TERM=xterm, e.g. see the Home/End keys Don't know of these, if so, then such issues should be reported against XTerm, respectively terminfo > let alone termcap/terminfo can't describe application keypad mode and > similar ones. same here,... And both are no reason for gnome to make things even worse, just because other do so as well. And actually most other terminals I've tested, seem to correctly announce their own name now - even rxvt does nowadays. > The definition needs to be deployed to every host you might log in to, > including those that are like 5 or 10 years old or even older, also > commercial Unix variants, good luck convincing all the vendors to ship a > vte-specific terminal description, and even if they do, they'll likely lag > behind by a few years. - It's fine to work around other problems, but only if this doesn't break new things. Here the solution is rather that *if* people connect to such hosts then the appropriate way is to override that either globally for their SSH (so that only remote connections are mangled up, or even just on a per host basis... which is really easy to do. - I work at one of the biggest super computing centres in Europe, we have all kinds of really old hosts, and those I've checked, even include gnome's definitions. - The same problem might apply for the xterm definition, it may be as out of date as gnome's/VTE's. So I don't quite see why GNOME/VTE should have a problem here (respectively need to solve a problem), which other terminals don't need to solve. > It's not versionable, e.g. xterm recently introduced support for italic text > and added the corresponding capability, yet there's no way to guarantee that > a pre-italic xterm matches with a pre-italic xterm terminfo definition, and > a post-italic matches a post-italic. Vte also regularly changes/fixes some > emulation issue or adds a new feature. Well but isn't that also just a problem for remote connections? And again, the same problem has xterm. > The terminfo only describes a small subset of the terminal's features. Not a > single word about e.g. which OSC sequences are supported, what sequences are > generated in application keypad mode, how the modifiers are encoded. No > possibilities to add custom extensions. > Probably the correct solution would have been to have $TERMCAP which fully > describes the capabilities, and is forwarded over ssh. I could imagine that this is a security issue. > There's no point in aiming for perfectness in a world when it can't be > achieved. Then you can only aim for "good enough", and for that > xterm(-256colors) is IMO a very good choice. By the way, konsole and > terminology also chose this path. Well just because others break things either, you don't need to follow them do you!? ;-) The proper solution would be for systems to keep their terminfo up-to-date (which is even on long term supported distros not that difficult) and all terminals (Konsole or whichever) should properly announce what they are. In reality, with keeping the current ugly practise you (meaning the upstreams of Terminal emulators) and justifying that by "best compatibility", you're actually 50% responsible for the very situation that is claimed to be worked around. It's a bit like the Unicode problem is still in many places, where people say: "Ah... Unicode isn't well supported yet, we can't support it therefore" And by that they just keep the situation as it is. > If there's a specific issue, let's discuss that separately. As for $TERM, I > think xterm-256colors is currently the most reasonable compromise. Well I guess I've laid out my reasons quite elaborately why I think gnome-256colors should be used (and the xterm, ncurses and terminfo upstream apparently suggests that as well - the website may be old, but I talked to him yesterday and it's still fully valid). However, what you could at least do, is to add a setting where people can chose which TERM they want to be announced by gnome-terminal. Actually you should make this even then possible, when you'd follow my wish and use gnome-256color. Cheers, Chris.
> > There are a numerous problems with $TERM per se. > Which? Not with a concrete value of $TERM, but the whole existence and the design of this variable. > It still seems to be *the* way for terminfo to know which terminal runs... > so legacy or not, it's still massively used. Sure (unfortunately). > > Not even xterm itself complies to TERM=xterm, e.g. see the Home/End keys > Don't know of these, if so, then such issues should be reported against > XTerm, respectively terminfo xterm and terminfo are maintained by the same guy. Here's perfectly aware of this, I've seen it documented somewhere (can't find it right away). Just quickly scroll though xterm's manpage: You'll find plenty of command line options that influence the emulation behavior, yet $TERM is always xterm. Now what? > And both are no reason for gnome to make things even worse, just because > other do so as well. There's no perfect way. There are disadvantages of hijacking another term description. There would be disadvantages with coming up with our terminal description too. Gnome-terminal has been there, done that, and changed for a good reason I assume; the developer of that era (Behdad, see his comments above) has a first-hand experience. Please accept his choice. > - I work at one of the biggest super computing centres in Europe, we have > all kinds of really old hosts, and those I've checked, even include > gnome's > definitions. An ancient unmaintained one that is probably way farther away from current gnome-terminal's behavior than TERM=xterm. > Well I guess I've laid out my reasons quite elaborately why I think > gnome-256colors should be used (and the xterm, ncurses and terminfo upstream > apparently suggests that as well - the website may be old, but I talked to > him yesterday and it's still fully valid). Why gnome-256colors? Vte supports 16M colors. There's no way to denote this feature in termcap, I wonder why... And why put one of the features in the _name_, whereas it should be a value? Why not call it gnome-16Mcolors-noitalic-rewraponresize-mouseextensions1015and1006-andsoon? :) *If* we went this direction at all, the name should be gnome or gnome-terminal or vte.
Ouch, I meant to type TERM=gnome-16Mcolors-noblink-rewraponresize-mouseextensions1015and1006-andsoon :D We do support italics :) > In reality, with keeping the current ugly practise you (meaning the upstreams > of Terminal emulators) and justifying that by "best compatibility", you're > actually 50% responsible for the very situation that is claimed to be worked > around. If it was a well designed system then I'd take blame for causing more mess – actually what I most enjoy is cleaning up mess and coming up with nice solutions. But it's not a well designed system, neither the distribution nor the versioning of these terminfo files is solved. (And that's why we prefer to hijack a value rather than coming up with our own, if it was a well-designed system we'd call ourselves as intended.) With these severe limitations, I'm sorry but I feel the _practical_ problems would outweight the _theoretical_ correctness. We contribute to the mess, but I don't feel guilt because it's not us who started it, and given the mess we started with it was the best we could do. Do you want to go for technical correctness? Okay! Let's design something that obsoletes $TERM and replaces it by something that solves all the problems with the current design. Something where I can modify vte and ssh to a remote host and that host will immediately know about the modified behavior. If you organize and lead it and get buy-in from a critical set of people/vendors, I'm happy to join! :) (No, I don't have time and motivation to lead this on my own.)
> And actually most other terminals I've tested, seem to correctly announce > their own name now - even rxvt does nowadays. Just one more comment: rxvt is notorious for being quite different from xterm, at least its escape sequences are not the same. With rxvt + TERM=xterm, apps would fail big time. On the other hand, vte uses xterm as the reference, we try to copy its emulation as closely as reasonable.
*** Bug 746618 has been marked as a duplicate of this bug. ***
(In reply to Egmont Koblinger from comment #64) > > > There are a numerous problems with $TERM per se. > > Which? > Not with a concrete value of $TERM, but the whole existence and the design > of this variable. Well that I can't really comment on much, since I'm no in depth expert. At least at a first glance it seems to me that stuff running inside a terminal might want to know what this is, and env vars seem to be the most portable way. The only direct problem I'd see is what happens if you have "multiple" terminal types running, e.g. gnome-terminal as the "real" on, inside that screen and so on. Of course, it also has the problem of out of date terminal definitions. So maybe these should get versioned (in an ideal world). > Sure (unfortunately). And that's not really going to change - at least I don't see that I'd live that long ;) > An ancient unmaintained one that is probably way farther away from current > gnome-terminal's behavior than TERM=xterm. Then a breaking terminal would probably a good reminder to scrap such machine ;) > Why gnome-256colors? Vte supports 16M colors. There's no way to denote this > feature in termcap, I wonder why... And why put one of the features in the > _name_, whereas it should be a value? Why not call it > gnome-16Mcolors-noitalic-rewraponresize-mouseextensions1015and1006-andsoon? > :) In principle I'd agree with that and I also don't like it about xterm. The terminal definition should be the name of the terminal and at most perhaps a version. > *If* we went this direction at all, the name should be gnome or > gnome-terminal or vte. Yes. (In reply to Egmont Koblinger from comment #65) > Ouch, I meant to type > TERM=gnome-16Mcolors-noblink-rewraponresize-mouseextensions1015and1006- > andsoon :D We do support italics :) ;-) The thing is, AFAIU, the problem of different versions or perhaps even different features compiled in or not only affects when you go on remote systems, right? A local system should (or at least could quite easily) have a fully consistent state of its terminal emulators vs. it terminfo definitions. Obviously, going remote *is* a major use case, but then it might be a better solution if the TERM should be set to something appropriate (whatever that is) by the remote shell. Could be a common basic set of escape sequences most likely shared. > If it was a well designed system then I'd take blame for causing more mess – > actually what I most enjoy is cleaning up mess and coming up with nice > solutions. But it's not a well designed system, neither the distribution nor > the versioning of these terminfo files is solved. Even though this goes off topic: How would you make it better? The only way I could think of right now, was by sending the "right" terminfo to the remote end, which however may be security critical. (In reply to Egmont Koblinger from comment #66) > > And actually most other terminals I've tested, seem to correctly announce > > their own name now - even rxvt does nowadays. > > Just one more comment: rxvt is notorious for being quite different from > xterm, at least its escape sequences are not the same. With rxvt + > TERM=xterm, apps would fail big time. On the other hand, vte uses xterm as > the reference, we try to copy its emulation as closely as reasonable. That wasn't the point I referred to: My point was, when "hijacking" xterm is so important for e.g. Konsole/GNOME-Terminal to work correctly at least in practise with the ill-designed world of terminfo,... then why can others set their TERM correctly, and still work without users running into all kinds of issues, especially(!) when - as you say - rxvt is so different?
(In reply to Christoph Anton Mitterer from comment #68) > The only direct problem I'd see is what happens if you have "multiple" > terminal types running, e.g. gnome-terminal as the "real" on, inside that > screen and so on. That shouldn't be a problem, screen takes care of the translation. > The thing is, AFAIU, the problem of different versions or perhaps even > different features compiled in or not only affects when you go on remote > systems, right? > A local system should (or at least could quite easily) have a fully > consistent state of its terminal emulators vs. it terminfo definitions. A local system can be fully consistent if the terminal definition is taken from the terminal emulator's source code, yet it's installed even if the emulator itself isn't (e.g. a separate package ships that sole file, with the terminfo package requiring it) so that it's available if you ssh to that server. It's doable, but I doubt distros would get into so much trouble. > Obviously, going remote *is* a major use case, but then it might be a better > solution if the TERM should be set to something appropriate (whatever that > is) by the remote shell. TERM is passed along by ssh, and ideally it shouldn't be altered. If you propose a change which has such inconvenience where the user can no longer rely on this and they need to change TERM on the remote machine, they'll scream out loud demanding to revert that change. > Even though this goes off topic: How would you make it better? > The only way I could think of right now, was by sending the "right" terminfo > to the remote end, which however may be security critical. Yup, sending the complete terminfo description (in a well-defined plaintext format). I can't see the security issue. > My point was, when "hijacking" xterm is so important for e.g. > Konsole/GNOME-Terminal to work correctly at least in practise with the > ill-designed world of terminfo,... then why can others set their TERM > correctly, and still work without users running into all kinds of issues, > especially(!) when - as you say - rxvt is so different? It takes years, many years until that definition is deployed anywhere. Maybe they started a long time ago. And of course, by design you can't make any incompatible changes without causing inconvenience to the user (but that's also the case with TERM=xterm).
(In reply to Egmont Koblinger from comment #69) > > The only direct problem I'd see is what happens if you have "multiple" > > terminal types running, e.g. gnome-terminal as the "real" on, inside that > > screen and so on. > That shouldn't be a problem, screen takes care of the translation. And at least theoretically, SSH should do so either. Especially since SSH adds it's own escape sequences... > TERM is passed along by ssh, and ideally it shouldn't be altered. If you > propose a change which has such inconvenience where the user can no longer > rely on this and they need to change TERM on the remote machine, they'll > scream out loud demanding to revert that change. Okay, but what else would you propose that is secure and handles the problem of potentially outdated terminal definitions on the remote side? > > Even though this goes off topic: How would you make it better? > > The only way I could think of right now, was by sending the "right" terminfo > > to the remote end, which however may be security critical. > Yup, sending the complete terminfo description (in a well-defined plaintext > format). I can't see the security issue. Well I think it's conceptually equal to why can be a security risk if the user can modify the locale that is used remotely. It changes the output/behaviour of programs and this may not be expected on the other side. > It takes years, many years until that definition is deployed anywhere. Maybe > they started a long time ago. And of course, by design you can't make any > incompatible changes without causing inconvenience to the user (but that's > also the case with TERM=xterm). AFAIU, they only started "behaving properly" not so long ago. Anyway,... I did some further thinking about the problem of inconsistent remote terminal definitions and the long time it takes for new ones to propagate. And now I wonder a bit, whether it's actually a big problem or not. Which cases can we basically have? a) A connection is made from a newer version of a terminal to a system with a older terminal definition. (I'd guess this is the typical case since usually people connect from their workstations which are more up to date than perhaps old servers). b) A connection is made from a older version of a terminal to a system with a newer terminal definition. What can happen then? 1) The remote system lacks a capability which I'd have in my terminal. => that shouldn't be a problem, the software runs remotely, if it properly checks for the capability, it sees "not supported" and simply doesn't use it 2) The remote system advertises a capability which I don't have yet terminal. => if remote software would use such caps, then this could of course be be bad, but as said: - typically I'm newer than remote - very new capabilities (like RGB colours) aren't used anyway by software (e.g. even no one really uses 256 colours) => so it's very likely that the actually used caps still work on both sides and even if not: - it seems that many newer caps (take the 256 colours, e.g. or the RGB colours are added in such way, that legacy terminals don't break (or did I get that wrong)? 3) caps have changed between two versions of a terminal emulator That would obviously really cause troubles, e.g. if VTE 1.0 uses \e[31m for red and in VTE it uses tha same for move cursor one line up. But do such kinds of changes ever happen? AFAIU the historical development of terminals (i.e. starting with true hardware terminals from DEC, HP or others, features were rather always added in a way not breaking with older things. Cheers, Chris.
(In reply to Christoph Anton Mitterer from comment #70) > And at least theoretically, SSH should do so either. > Especially since SSH adds it's own escape sequences... Just because it has its own escape sequences, it doesn't mean it should emulate a terminal. It doesn't, and honestly, why should it? Screen/tmux are terminal emulators, they have to be by their nature. Ssh doesn't have to be, and it would be a source of tons of problems if it would. > Well I think it's conceptually equal to why can be a security risk if the > user can modify the locale that is used remotely. > It changes the output/behaviour of programs and this may not be expected on > the other side. You being able to tweak your programs to misbehave by giving it intentionally faulty settings is never a security issue. That's the expected behavior. (Someone else being able to tweak your programs to misbehave is a totally different story, that's indeed a security hole.) I'm sorry but I don't have time nor motivation to continue this discussion, and even if I had, this bugzilla entry probably wouldn't be the right forum. I can't tell exactly upfront how I'd design such a system, it'd be a long process. It's clear by now that this won't happen. I told you in which direction I'd start, but I don't have time to walk along this road.
We now use xterm-256color by default, so this bug is FIXED as the request in comment 0 is satisfied.