- Package:
- gnome-terminal
- Source:
- gnome-terminal
- Description:
- GNOME terminal emulator application
- Submitter:
- James Vega
- Date:
- 2015-06-15 19:15:28 UTC
- Severity:
- normal
Package: gnome-terminal Version: 2.14.1-1 Severity: normal Tags: patch Gnome-terminal incorrectly claims to be xterm-compatible in it's $TERM. This should instead be set to gnome, which is the proper termcap entry for gnome-terminal. The attached patch fixes the hard-coded TERM entry in gnome-terminal's source. James
tags 368916 + confirmed upstream
tags 368916 - patch
forwarded 368916 http://bugzilla.gnome.org/show_bug.cgi?id=115750
stop
Hi,
Thanks for your report, I've linked the Debian bug to an upstream
discussion (which you might want to subscribe to) on a similar topic.
(I'm removing the patch keyword because I'd like upstream feedback.)
Bye,
Seeing not much progress on this issue upstream, a patch on the Debian side would be useful, I think. The variable actually should be TERM=gnome-256color, which is included in the "ncurses-term" package. A dependency on this package should be introduced together with the patch (kterm depends on it as well, so that shouldn't be much of a problem).
This is feasible, but we’d need to test it on a wide scale, because it could break a lot of things. Daniel, do you know how the gnome-* terminfo entries were written? Are they actually based on the vte capabilities? If they do, why not shipping them directly in the vte packages?
I wrote the gnome* terminfo entries. gnome developers iirc have a copy of the "xterm" terminfo in their sources. vte, for practical purposes, is undocumented. I write/update terminfo entries when I happen to notice that the gnome developers have made some change which invalidates the terminfo.
Anything new here?
Apparently upstream intentionally breaks things or simply doesn't care.
So could Debian please fix things at least downstream?
The patch is trivial, and having tested it with all kinds of
applications, it seems to not cause breakage.
Having set the wrong TERM breaks all kinds of things and there is no
real way to correct that (setting it in .bashrc or friends would do this
for all terminals!).
Below is a list of differences between xterm and gnome and for
xterm-256color / gnome-256color things are not better.
Reporting the wrong terminal doesn't only lead to some features not
working, it also means that tests for features fail, e.g. tput blink
will exit 0 on gnome terminal, while it should exit 1 (since it doesn't
support blinking).
Further, I'd suggest that gnome-terminal sets TERM=gnome-256color
instead of just gnome.
It actually already supports full RGB colours so there's no reason to
restrict oneself.
Cheers,
Chris.
$ infocmp xterm gnome
comparing xterm to gnome.
comparing booleans.
km: T:F.
mc5i: T:F.
npc: T:F.
comparing numbers.
ncv: NULL, 16.
comparing strings.
blink: '\E[5m', NULL.
cbt: '\E[Z', NULL.
cnorm: '\E[?12l\E[?25h', '\E[?25h'.
cvvis: '\E[?12;25h', NULL.
el1: '\E[1K', NULL.
enacs: NULL, '\E)0'.
flash: '\E[?5h$<100/>\E[?5l', NULL.
ich: '\E[%p1%d@', NULL.
indn: '\E[%p1%dS', NULL.
is2: '\E[!p\E[?3;4l\E[4l\E>', '\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8'.
kb2: '\EOE', '\E[E'.
kent: '\EOM', NULL.
kf13: '\E[1;2P', '\EO1;2P'.
kf14: '\E[1;2Q', '\EO1;2Q'.
kf15: '\E[1;2R', '\EO1;2R'.
kf16: '\E[1;2S', '\EO1;2S'.
kf25: '\E[1;5P', '\EO1;5P'.
kf26: '\E[1;5Q', '\EO1;5Q'.
kf27: '\E[1;5R', '\EO1;5R'.
kf28: '\E[1;5S', '\EO1;5S'.
kf37: '\E[1;6P', '\EO1;6P'.
kf38: '\E[1;6Q', '\EO1;6Q'.
kf39: '\E[1;6R', '\EO1;6R'.
kf40: '\E[1;6S', '\EO1;6S'.
kf49: '\E[1;3P', '\EO1;3P'.
kf50: '\E[1;3Q', '\EO1;3Q'.
kf51: '\E[1;3R', '\EO1;3R'.
kf52: '\E[1;3S', '\EO1;3S'.
kf61: '\E[1;4P', '\EO1;4P'.
kf62: '\E[1;4Q', '\EO1;4Q'.
kf63: '\E[1;4R', '\EO1;4R'.
kfnd: NULL, '\E[1~'.
kslt: NULL, '\E[4~'.
mc0: '\E[i', NULL.
mc4: '\E[4i', NULL.
mc5: '\E[5i', NULL.
rin: '\E[%p1%dT', NULL.
rmacs: '\E(B', '^O'.
rmcup: '\E[?1049l', '\E[2J\E[?47l\E8'.
rmso: '\E[27m', '\E[m'.
rmul: '\E[24m', '\E[m'.
rs2: '\E[!p\E[?3;4l\E[4l\E>', '\E7\E[r\E8\E[m\E[?7h\E[!p\E[?1;3;4;6l\E[4l\E>\E[?1000l\E[?25h'.
setb: '\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.
setf: '\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.
sgr: '%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m', '\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p5%t;2%;%?%p7%t;8%;%?%p1%p3%|%t;7%;m%?%p9%t\016%e\017%;'.
sgr0: '\E(B\E[m', '\E[0m\017'.
smacs: '\E(0', '^N'.
smcup: '\E[?1049h', '\E7\E[?47h'.
u8: '\E[?1;2c', '\E[?%[;0123456789]c'.
Hi, I've been an active contributor/developer of gnome-terminal in the last 1.5 years. I firmly disagree with Christoph's comment "Apparently upstream intentionally breaks things or simply doesn't care." We do care, and we worked hard recently to make gnome-terminal work reasonably close to xterm. Just look at the changelog and count how many emulation fixes we had in the last 1.5 years! Gnome-terminal has set TERM=xterm for a long time, and xterm is our reference as for how the terminal should work. On the other hand, TERM=gnome, which is written and maintained (probably not maintained actively too much) by xterm/terminfo's maintainer, is probably way out of date. Without looking at the details, I'm quite sure that TERM=xterm is way closer to describe gnome-terminal's behavior than TERM=gnome. And even if someone updates and corrects the "gnome" terminal description, we'd have to wait years until it's deployed to most of the hosts where you'd want to ssh to. Sure it's not perfect, but incorrectly reporting blink support is probably a magnitudes smaller problem than the ones you'd face with TERM=gnome. *If* someone updates TERM=gnome and keeps it updated, changing to that as the default might become a viable option in maybe 5 years or so. Over the last year or two we fixed plenty of _actual_ bugs where the emulation was incorrect. Christoph found the tinyest and most negligible feature that we promise to support but actually don't (i.e. blinking), and riding this he wants to push towards a completely different design which would have way more severe bugs which he can't foresee. With further details/discussions in the mainstream bugreport, I recommend that Debian developers stick to gnome-terminal developers' choice. cheers, egmont
Hey. Well at least it was changed (as it was said in some other discussion) from properly announcing it as "vte" or something like that to some wrong value... so one could interpret this as intention ;) And that issues has been open for quite a while, with the fix being trivial, so since I didn't really assume bad faith on the upstream side, I concluded it must be lack of interest. I never said you'd be doing bad work in creating a terminal itself or making it close in behaviour to xterm, actually gnome-terminal/VTE is my favourite terminal emulator. But the idea of terminal names in terminfo is not that there is a common base set which all have to try to implement as closely as possible - and everything beyond that may just cause issues. Actually that's one of the basic ideas of terminfo to make terminals usable in an end-device independent manner. As soon as xterm would change something, gnome-terminal would be out of sync for at least a while, and this already assumes that "perfect" compatibility can be reached. And the other way round: Since some other terminal emulators choose to announce themselves as "xterm" it also makes life of the real XTerm much hard in that they probably must think twice before they could do a change to their terminal definitions, knowing that this would break with n other terminals. As I've mentioned in the discussions, I didn't get the opinion that the upstream of Xterm/ncruses/terminfo were particularly happy about that situation - but maybe I just misunderstood them. Hmm well that's another topic. But at least for the few things I tried now, "gnome" seemed to have produced better results. Well we had that very same discussion over at the GNOME bugzilla: The problem you describe isn't really much different from when you or anyone else use "xterm". As soon as that changes it would also takes years to propagate. Just out of curiosity, which problems are known? I run with "gnome-256color" for a while now and everything seems to run smoothly. Not sure how the responsibilities are laid out there, but shouldn't the upstream of each terminal emulator make sure to ship a proper definition or at least keep it updated over at ncurses/terminfo? Cheers, Chris.
Sorry, I meant "real" in the sense of "portable". Of course one can always find out somehow, and if by using ps(1), but I don't want to maintain a list of variable which dozens of terminal emulator set or set not, just to find out what's actually running. This is the job of terminfo, and if someone would write now another layer to correctly detect things because terminfo is fooled, it would likely just take a few years until that is als fooled by just setting these variables (just see how many browsers announce themselves as Mozilla ^^). Best wishes, Chris.