Top 'Xterm': Unknown Terminal Type

xterm-new': unknown terminal type

As mikyra pointed out in the comments above, setting the environment variable TERM=xterm-256color solves the problem.

To summarize:

# Run the following commands on the local machine's bash prompt
echo "export TERM=xterm-256color" >> ~/.bashrc
source ~/.bashrc

ssh into remote machine and run the commands you like. The same xterm-new error should not occur now.

yet another unknown terminal type

Your shell may set TERMINFO to some other location than /usr/share/terminfo, and confuse the ncurses library. The ncurses library has a compiled-in fallback value for TERMINFO, which can be overridden by setting the environment variable.

You may also have (from packages or the like, e.g., homebrew) a copy of clear in your path before /usr/bin/clear which points to an incomplete terminal database.

For the latter, "which clear" would show where that is the case. If you also have infocmp, the same information is available, e.g., in the first line of its output.

It is also possible to have a corrupted terminal database (why, I cannot say), and because the ncurses library makes some runtime checks on each entry, it could refuse to load those without apparent cause.

Failing cronjob: 'unknown': unknown terminal type

top's -b (Batch-mode) and -n (Number-of-iterations) options helped.

By default top is interactive so I have fetch a static result to save it into a file.

Example: top -b -n1

nano error: Error opening terminal: xterm-256color

On Red Hat this worked for me:

export TERM=xterm

further info here: http://www.cloudfarm.it/fix-error-opening-terminal-xterm-256color-unknown-terminal-type/

How can I fix unknown terminal type when connecting with Perl's Net::Telnet?

If you use the option_log function to log the telnet options received and returned. You will see that Perl does not send the terminal type to the server by default. Server will default the terminal type to "network" for some reasons.

The right way to do this is to set the terminal type on the perl side.

my $termtype = 'vt100'; my $telopt_ttype_ok = '';
my $t = new Net::Telnet (Timeout => 5);

$t->option_callback(\&opt_callback);
$t->option_accept(Do=>Net::Telnet->TELOPT_TTYPE);
$t->suboption_callback(\&subopt_callback);

$t->open($server);
$t->input_log("runRemoteCommand_telnet.log");
$t->login($user, $pass);
$t->cmd($command);

exit 0;

sub opt_callback { 
  my ($obj, $option, $is_remote, $is_enabled, $was_enabled, $buf_position) = @_;
  if ($option == Net::Telnet->TELOPT_TTYPE and $is_enabled and !$is_remote) {
    $telopt_ttype_ok = 1; 
   }
   1;
}

sub subopt_callback {
 my ($obj, $option, $parameters) = @_; 
 my ($ors_old, $otm_old);
 if ($option == Net::Telnet->TELOPT_TTYPE) 
 {
  $ors_old = $obj->output_record_separator('');
  $otm_old = $obj->telnetmode (0);
  $obj->print("\xff\xfa", pack("CC", $option, 0), $termtype, "\xff\xf0");
  $obj->output_record_separator($ors_old);
  $obj->telnetmode ($otm_old);
 }
 1;
}

Refer to this

Error opening terminal: xterm-256color

Probably due to a Lion upgrade/install. Did you do that recently @Gih?

Possible duplicate (with fix) at
nano error: Error opening terminal: xterm-256color

EDIT:

Easiest fix (takes 10 seconds)...from Michael:

There is a solution much easier:
http://ricochen.wordpress.com/2011/07/23/mac-os-x-lion-terminal-color-remote-access-problem-fix/

Can't use clear command on terminal (Mac OS X)

Terminal.app is setting the TERM environment variable according to the menu entry, so exporting it does not address the problem. (Setting TERM has no effect on the behavior of Terminal.app, but that is a different mattern).

OSX (and most Unix-like) systems use terminfo for finding terminal information. If the environment variable TERMINFO is set, the ncurses library uses that path in preference to the compiled-in location (which is supposed to match the installed-location).

Your shell may have set the TERMINFO variable (for instance, by copying settings from another machine). Removing it from the shell initialization (such as ~/.profile or ~/.bashrc) is a way to fix that.

Alternatively, you may (as in tput: unknown terminal “xterm-256color”) have installed some not-mentioned package which conflicts with the ncurses libraries on the system. In that discussion, it seems that someone built ncurses libraries which had compiled-in default for TERMINFO to a non-existent location. For that case, I pointed out that the OP could set TERMINFO to tell the broken libraries where to find the terminal database. That is,

export TERMINFO=/usr/share/terminfo

would be a first step.

TERM environment variable not set

You can see if it's really not set. Run the command set | grep TERM.

If not, you can set it like that:
export TERM=xterm

---

Related Topics