Debian – Where is the `$TERM` environmental variable set in Debian Jessie for console logins

Sudo has many compile-time configuration options. You can list the settings in your version with sudo -V. One of the differences between the configuration in Debian wheezy and in Ubuntu 12.04 is that the HOME environment variable is preserved in Ubuntu but not in Debian; both distributions erase all environment variables except for a few that are explicitly marked as safe to preserve. Thus sudo -s preserves HOME on Ubuntu, while on Debian HOME is erased and sudo then sets it to the home directory of the target user.

You can override this behavior in the sudoers file. Run visudo to edit the sudoers file. There are several relevant options:

• env_keep determines which environment variables are preserved. Use Defaults env_keep += "HOME" to retain the caller's HOME environment variable or Defaults env_keep -= "HOME" to erase it (and replace it by the home directory of the target user).
• env_reset determines whether environment variables are reset at all. Resetting environment variables is often necessary for rules that allow running a specific command, but does not have a direct security benefit for rules that allow running arbitrary commands anyway.
• always_set_home, if set, causes HOME to be overridden even if it was preserved due to env_reset being disabled or HOME being in the env_keep list. This option has no effect if HOME isn't preserved anyway.
• set_home is like always_set_home, but only applies to sudo -s, not when calling sudo with an explicit command.

These options can be set for a given source user, a given target user or a given command; see the sudoers manual for details.

You can always choose to override HOME for a given call to sudo by passing the option -H.

The shell will never override the value of HOME. (It would set HOME if it was unset, but sudo always sets HOME one way or another.)

If you run sudo -i, sudo simulates an initial login. This includes setting HOME to the home directory of the target user and invoking a login shell.

There is some information on 256-color support in the tmux FAQ.

Detecting the number of colors that the terminal supports is unfortunately not straightforward, for historical reasons. See Checking how many colors my terminal emulator supports for an explanation. This means that

• tmux cannot reliably determine whether the terminal supports more than 8 colors;
• tmux cannot reliably communicate to the application that it supports more than 8 colors.

When you're in tmux, the terminal you're interacting with is tmux. It doesn't support all of xterm's control sequences. In particular, it doesn't support the OSC 4 ; … control sequence to query or set color values. You need to use that while directly running in xterm, outside tmux.

If you run tmux -2, then tmux starts with 256-color support, even if it doesn't think that your terminal supports 256 colors (which is pretty common).

By default, tmux advertises itself as screen without 256-color support. You can change the value of TERM in .tmux.conf to indicate 256-color support:

set -g default-terminal "screen-256color"

You can use TERM=xterm-256color or TERM=screen-256color on Ubuntu. These values will only cause trouble if you log in to a remote machine that doesn't have a termcap/terminfo entry for these names. You can copy the entries to your home directory on the remote machine; this works with most modern terminfo implementations.

# From the Ubuntu machine to a machine that doesn't have *-256color terminfo entries
ssh somewhere.example.com mkdir -p .terminfo/s .terminfo/x
scp -p /lib/terminfo/s/screen-256color somewhere.example.com:.terminfo/s/
scp -p /lib/terminfo/x/xterm-256color somewhere.example.com:.terminfo/x/