Bug 1166428

As far as I remember, the reason is that some people ssh into systems that don't have "xterm-256color" terminfo entry. "xterm" is more compatible with the crazy/ancient systems out there. (NB. I'd totally stay away from setting TERM to anything rxvt-related.)

If so far you relied on $COLORTERM for a workaround, you can now instead rely on $VTE_VERSION for the same workaround :)

I tend to agree that xterm-256color would be a better default, and if some system doesn't support it then the workaround should happen there.

On a slightly related note: gnome-terminal supports 16M true colors, but no terminfo entry exists for this feature.

(In reply to Egmont Koblinger from comment #1)
> As far as I remember, the reason is that some people ssh into systems that
> don't have "xterm-256color" terminfo entry. "xterm" is more compatible with
> the crazy/ancient systems out there. (NB. I'd totally stay away from setting
> TERM to anything rxvt-related.)
But we're not using "xterm" anywhere in reality, since basically everyone runs 256colors.sh in their shell and changes "xterm" to "xterm-256color". The initial setting from gnome-terminal would only matter if someone run ssh directly in the terminal emulator and not through a shell.

> If so far you relied on $COLORTERM for a workaround, you can now instead
> rely on $VTE_VERSION for the same workaround :)
That's not satisfying either ;)

> I tend to agree that xterm-256color would be a better default, and if some
> system doesn't support it then the workaround should happen there.
Yes. Can we do the switch please?

> On a slightly related note: gnome-terminal supports 16M true colors, but no
> terminfo entry exists for this feature.
Then we should get the terminfo entry, make it widely available in Fedora and on Debian and advertise it to other systems, and then at some point we should be able to switch gnome-terminal to it fairly painlessly. But that's another story.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #2)

> But we're not using "xterm" anywhere in reality, since basically everyone
> runs 256colors.sh in their shell and changes "xterm" to "xterm-256color".

This is RedHat/Fedora-specific. Mainstream gnome-terminal should also consider users of other distros, the pros and cons they'd face.

> The initial setting from gnome-terminal would only matter if someone run ssh
> directly in the terminal emulator and not through a shell.

That's a good point, and this is where it becomes more important to advertise 256-color support.

> > If so far you relied on $COLORTERM for a workaround, you can now instead
> > rely on $VTE_VERSION for the same workaround :)
> That's not satisfying either ;)

Just for curiosity: how is it any worse than looking at XTERM_VERSION, ROXTERM_ID or KONSOLE_DBUS_SESSION, as already done in 256term.sh? ;)

> > I tend to agree that xterm-256color would be a better default, and if some
> > system doesn't support it then the workaround should happen there.
> Yes. Can we do the switch please?

Filed https://bugzilla.gnome.org/show_bug.cgi?id=740641

> Then we should get the terminfo entry, make it widely available in Fedora
> and on Debian and advertise it to other systems, and then at some point we
> should be able to switch gnome-terminal to it fairly painlessly. But that's
> another story.

This is a long complicated story. I probably wasn't clear at all: there's absolutely no terminfo capability anywhere that would define true colors, first we'd need to agree on one with terminfo's maintainer.

Another thing is that gnome-terminal (vte) uses xterm as the reference most of the time, and uses TERM=xterm*. There were times when it set it to TERM=vte or TERM=gnome or alike, but it was damn problematic, all systems lagging behind by ages in having this terminfo installed. And, guess what, xterm doesn't support 16M colors, so g-t would need to diverge and start using its own TERM with all its disadvantages...

Let's focus on 256 colors now :)

(In reply to Egmont Koblinger from comment #3)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #2)
> > But we're not using "xterm" anywhere in reality, since basically everyone
> > runs 256colors.sh in their shell and changes "xterm" to "xterm-256color".
> 
> This is RedHat/Fedora-specific. Mainstream gnome-terminal should also
> consider users of other distros, the pros and cons they'd face.
I think all distros are pretty similar here. At least the ones that
are likely to package recent gnome3 versions, which tends to go with
having a fairly recent stack all over the place.

> > The initial setting from gnome-terminal would only matter if someone run ssh
> > directly in the terminal emulator and not through a shell.
> 
> That's a good point, and this is where it becomes more important to
> advertise 256-color support.
> 
> > > If so far you relied on $COLORTERM for a workaround, you can now instead
> > > rely on $VTE_VERSION for the same workaround :)
> > That's not satisfying either ;)
> 
> Just for curiosity: how is it any worse than looking at XTERM_VERSION,
> ROXTERM_ID or KONSOLE_DBUS_SESSION, as already done in 256term.sh? ;)
1. it is an additional script to run at every shell invocation
2. initscripts should be an optional package, we don't want it to influence behaviour of
   unrelated packages like terminal emulators
3. initscripts acts a centralized gatekeeper, and every new terminal emulator
   must "register" for proper support and every terminal which updates for 256 color
   support must coordinate with initscripts.
4. separate support must be provided for each shell.
   For example, gnome-terminal -e dash does not sport 256 colors. The same is
   probably true for many alternative shells.
5. (repeating from above) ssh and other programs run directly in a separate terminal
   window don't get support 'gnome-terminal -e mutt'...
6. If I ssh from outside, using an emulator which does not support 256 colors,
   I get silently "upgraded" to TERM=xterm-256color and things break.

> > > I tend to agree that xterm-256color would be a better default, and if some
> > > system doesn't support it then the workaround should happen there.
> > Yes. Can we do the switch please?
> 
> Filed https://bugzilla.gnome.org/show_bug.cgi?id=740641
Thanks.
 
> Let's focus on 256 colors now :)
+1

I agree that 256term.sh is not the right approach for the long term. The proper approach would require xterm, konsole, gnome-terminal etc. to be modified.

However, until this happens, updating 256term.sh to check for VTE_VERSION is the easiest quickest workaround that brings back advertising 256 colors at least for shells running inside gnome-terminals, as it used to be.  This is something Fedora should do right away, to not introduce any regression in gnome-terminal.

Any particular reason not to do sed s/xterm/xterm-256color/ in gnome-terminal or vte instead?

(In reply to Zbigniew Jędrzejewski-Szmek from comment #6)
> Any particular reason not to do sed s/xterm/xterm-256color/ in
> gnome-terminal or vte instead?

Not that I'm aware of, but gnome-terminal's maintainer has the final word, and that's not me.

Even if this happens, it will arrive in Gnome 3.16 next spring, meaning it'll be broken in F21.

Fedora should apply a quick fix, either doing the sed in their vte, or replacing COLORTERM by VTE_VERSION in 256test.sh, so that it's fixed in F21.

Created attachment 962336 [details]
Flip the default to TERM=xterm-256color

Fixed in mainstream vte git.

Still, Fedora should somehow fix it for F21.

vte291-0.38.2-3.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/vte291-0.38.2-3.fc21

Package vte291-0.38.2-3.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing vte291-0.38.2-3.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-16166/vte291-0.38.2-3.fc21
then log in and leave karma (feedback).

vte291-0.38.2-3.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.