#368916 gnome-terminal: $TERM should be set to gnome instead of xterm

Package:
gnome-terminal
Source:
gnome-terminal
Description:
GNOME terminal emulator application
Submitter:
James Vega
Date:
2015-06-15 19:15:28 UTC
Severity:
normal
#368916#5
Date:
2006-05-25 22:03:43 UTC
From:
To:
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

#368916#10
Date:
2006-06-08 09:24:03 UTC
From:
To:
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,

#368916#21
Date:
2007-12-22 17:23:40 UTC
From:
To:
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).

#368916#26
Date:
2007-12-25 16:49:33 UTC
From:
To:
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?

#368916#31
Date:
2007-12-25 20:50:29 UTC
From:
To:
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.

#368916#40
Date:
2015-03-22 20:56:34 UTC
From:
To:
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'.

#368916#45
Date:
2015-03-23 13:11:11 UTC
From:
To:
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

#368916#50
Date:
2015-03-23 13:23:21 UTC
From:
To:

#368916#55
Date:
2015-03-23 16:28:45 UTC
From:
To:
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.

#368916#60
Date:
2015-03-23 16:32:16 UTC
From:
To:
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.