Not reproducible with gnome-terminal 2.32.0.

gnome-terminal 2.32.0 works fine but it breaks other terminal programs that depend on vte-devel as part of their build process such as

lxterminal
sakura
guake
terminal

Breakage occurred after vte 24.3.

seems that this commit broke it:

http://git.gnome.org/browse/vte/commit/?h=vte-0-26&id=0574bcfbd5c5925458ecdea0e6bbac6d65e30efc

I backed out the commit as a test but still getting this error if I type top in lxterminal, sakura, terminal etc...

[texstar@localhost ~]$ top
TERM environment variable not set.

I can type in the terminal
TERM=xterm
export TERM

or 

TERM=linux
export TERM

then top will run in said terminals.

Just a quick follow up. With vte 0.24.3 installed I get in lxterminal

[texstar@localhost ~]$ printenv TERM
xterm

with vte 0.26.0 I get nothing.

[texstar@localhost ~]$ printenv TERM
[texstar@localhost ~]$

Yeah, this breaks Xfce's Terminal as well. 

See: https://bugzilla.redhat.com/show_bug.cgi?id=639280

(along with roxterm, lxterminal, and likely many others). 

What was the reason for this commit? Can we get it reverted?

Comment 4 says the referenced commit doesn't cause this.

I still can't repro this in either gnome-terminal or vteapp.

My work around for vte 0.26.0 for now is to edit my /etc/environment file and add

TERM=xterm

Not sure how this will affect my system elsewhere but it fixes all of my terminals that depend on vte.

I reverted that commit and did a build and it sure seems to fix roxterm and Xfce Terminal here. 

Fedora scratch build at: 
http://koji.fedoraproject.org/koji/taskinfo?taskID=2506797


diff -Nur vte-0.26.0.orig/src/vte.c vte-0.26.0/src/vte.c
--- vte-0.26.0.orig/src/vte.c	2010-09-26 12:34:04.000000000 -0600
+++ vte-0.26.0/src/vte.c	2010-10-01 13:06:21.994294036 -0600
@@ -3518,32 +3518,6 @@
         return argv2;
 }
 
-/*
- * _vte_terminal_filter_envv:
- * @envv: the environment vector
- *
- * Filters out the TERM variable from @envv.
- *
- * Returns: (transfer container): the filtered environment vector
- */
-static char **
-_vte_terminal_filter_envv (char **envv)
-{
-  GPtrArray *array;
-  int i;
-
-  if (envv == NULL)
-    return NULL;
-
-  array = g_ptr_array_sized_new (g_strv_length (envv));
-  for (i = 0; envv[i]; ++i)
-    if (!g_str_has_prefix (envv[i], "TERM="))
-      g_ptr_array_add (array, envv[i]);
-  g_ptr_array_add (array, NULL);
-
-  return (char **) g_ptr_array_free (array, FALSE);
-}
-
 /**
  * vte_terminal_fork_command:
  * @terminal: a #VteTerminal
@@ -3580,7 +3554,7 @@
                           gboolean utmp,
                           gboolean wtmp)
 {
-        char **real_argv, **real_envv;
+        char **real_argv;
         GSpawnFlags spawn_flags;
         GPid child_pid;
         gboolean ret;
@@ -3596,19 +3570,17 @@
         spawn_flags = G_SPAWN_CHILD_INHERITS_STDIN |
                       G_SPAWN_SEARCH_PATH;
         real_argv = _vte_terminal_get_argv (command, argv, &spawn_flags);
-        real_envv = _vte_terminal_filter_envv (envv);
 
         ret = vte_terminal_fork_command_full(terminal,
                                              __vte_pty_get_pty_flags(lastlog, utmp, wtmp),
                                              working_directory,
                                              real_argv,
-                                             real_envv,
+                                             envv,
                                              spawn_flags,
                                              NULL, NULL,
                                              &child_pid,
                                              err);
         g_strfreev (real_argv);
-        g_free (real_envv);
 
 #ifdef VTE_DEBUG
         if (error) {

I'm really not sure why, but the revert seems to work here. 

Texstar: Can you try again reverting it and confirm it does or does not fix it for you?

Ok. I will try it again. Thanks.

Tex

i have the confirmation here: https://bugs.archlinux.org/task/21007

I'm still getting nothing here with the reverted patch darn it. I'm not a coder but it seems to me maybe a fix would be to set envv to xterm if it equals NULL.  

if (envv == NULL)
   return NULL;

I'm curious now to see if the reverted patch works for Ubuntu.

I don't think reverting the commit http://git.gnome.org/browse/vte/commit/?h=vte-0-26&id=0574bcfbd5c5925458ecdea0e6bbac6d65e30efc will do anything. The bug was confirmed on Ubuntu for 0.25.91 and 0.26, and this commit was introduce between the 2 versions.

bisected and isolated the bug to commit: http://git.gnome.org/browse/vte/commit/?id=dd08c50c6a6dd4349d3cbce271ddf4b741db8861

previous revisions work fine with guake on x86_64. anything after this does not. It's a pretty big commit and contains probably pretty fundamental changes.

Created attachment 171897 [details] [review]
set TERM variable on terminal initialization

The difference with gnome-terminal (and probably vteapp as well), is that they define TERM as xterm no matter what happens... On the other hand it looks like many terminal programs (or at least those affected), just do not touch TERM, probably relying on vte to set it. Gnome in general does not seem to pass the TERM environment variable when launching programs from the menus at least.

My take is that VTE should at least specify TERM if unset when a vte_terminal is initialized.

Comment on attachment 171897 [details] [review]
set TERM variable on terminal initialization

This 'patch' is a bad joke, right?

*** This bug has been marked as a duplicate of bug 631589 ***

vte 0.26.1 has fixed the problem for me. Thank you gnome devs!