TERM unconditionally set to "xterm", regardless of config

Bug #778801 reported by Micah Cowan
72
This bug affects 15 people
Affects Status Importance Assigned to Milestone
Gnome Virtual Terminal Emulator
Invalid
Medium
xfce4-terminal
Unknown
Unknown
vte (Ubuntu)
Fix Released
Low
Unassigned
xfce4-terminal (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: xfce4-terminal

Xubuntu 11.04 Natty Narwhal

xfce4-terminal 0.4.7-0ubuntu1
libvte9 0.27.90

I wish to enable 256-color support in apps running under xfce4-terminal; but even though I've set TERM to this value in the config (and verified it in .config/Terminal/terminalrc), the TERM variable winds up having the value "xterm".

Upon digging a little further, xfce4-terminal correctly sets the TERM variable in the environment vector that it then passes through to vte via vte_terminal_command_full (this takes place within the terminal_screen_launch_child function found in terminal/terminal-screen.c). However, vte_terminal_fork_command_full copies everything from that vector _except_ the TERM variable, unconditionally replacing that with a value that should be set by calling vte_pty_set_term (this happens in src/pty.c:__vte_pty_merge_environ(), which is called by (and gets the TERM value from) src/pty.c:__vte_pty_spawn, which in turn is called by src/vte.c:vte_terminal_fork_command_full() ). xfce4-terminal doesn't appear to ever call that function anywhere, and thus vte defaults to "xterm". So the appropriate fix would seem to be to make xfce4-terminal call that function to register the correct TERM value.

Revision history for this message
Micah Cowan (micahcowan) wrote :

Er, vte_pty_set_term isn't callable, since the pty object doesn't exist before __vte_pty_spawn. The user-callable fn is vte_terminal_set_emulation.

Revision history for this message
Micah Cowan (micahcowan) wrote :

According to the discussion on the Gnome VTE bug linked, calling vte_terminal_set_emulation won't work either, unless it happens to be recognized as a supported emulation mode. "xterm-256color" isn't, so this solution wouldn't work.

There doesn't seem to be an obvious, clean way to fix the problem within xfce4-terminal; vte is the one holding all the cards AFAICT. According to discussion on the Gnome VTE bug, vte_terminal_fork_command_full is "just a wrapper" around some other functions, but one of those functions (__vte_pty_spawn) probably isn't safe to call by users.

Perhaps the correct solution should be for vte to revert to its previous behavior, whereby it didn't brutally murder pre-existing TERM settings when the terminal app sets them. If the upstream vte folks don't want to consider this, Ubuntu probably should.

Revision history for this message
Micah Cowan (micahcowan) wrote :

Added vte, until it's clearer which of xfce4-terminal and vte should fix this (as I said, though, it looks to me like only vte _can_ fix it, though upstream seems unwilling).

Revision history for this message
Micah Cowan (micahcowan) wrote :

Note that gnome-terminal isn't effected, since gnome-terminal doesn't give the user the option to specify the TERM value to begin with. This is generally a desirable feature to have, though.

Changed in vte:
importance: Unknown → Medium
status: Unknown → New
Changed in vte (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xfce4-terminal (Ubuntu):
status: New → Confirmed
Revision history for this message
Henning Hoefer (hoeferh) wrote :

This bug seems to be still present in Xubuntu 11.10

Revision history for this message
Gytis Žilinskas (gytis-zilinskas) wrote :

still present and very very annoying

Revision history for this message
Ivan Frederiks (idfred) wrote :

Still present in Precise.

Revision history for this message
Ryan Kinderman (wizderman) wrote :

Still present in Quantal.

Revision history for this message
TK (tkrishan) wrote :

Still present in Raring

Revision history for this message
Micah Cowan (micahcowan) wrote :

FWIW, the workaround I've been using for some time now is:

if [ \( "x$COLORTERM" = "xgnome-terminal" -o "x$COLORTERM" = "xTerminal" -o "x$COLORTERM" = "xxfce4-terminal" \) -a "x$TERM" = "xxterm" ] &&
        infocmp xterm-256color >/dev/null 2>&1; then
    TERM=xterm-256color
fi

in my .bashrc or what have you. The "Terminal" was what worked in Precise and prior; "xfce4-terminal" is what COLORTERM is now set to.

(The infocmp command verifies that there is a terminfo database entry for "xterm-256color", so it doesn't get set and then terminal apps haven't a clue how to talk to the terminal.)

Revision history for this message
Micah Cowan (micahcowan) wrote :

(the line wrapped for the first "if" line; that needs to be a single line to work)

Changed in vte:
status: New → Invalid
Revision history for this message
Ash (flubba86) wrote :

Is there any chance of this being looked at? I use XFCE4 and this bug affects me.

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

FYI: Newer versions of vte/gnome-terminal set TERM=xterm-256color (hardcoded; no config option available).

Revision history for this message
Theo Linkspfeifer (lastonestanding) wrote :

https://git.xfce.org/apps/xfce4-terminal/commit/?id=fa9d95c99d3c73c80fc42fbc23b73a5a8d5bae79

The config option was removed in xfce4-terminal also. Like mentioned in the previous comment, it is TERM=xterm-256color by default now.

Changed in vte (Ubuntu):
status: Triaged → Fix Released
Changed in xfce4-terminal (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.