PuTTY tips for Debian users

[Stephen Powell <zlinuxman@wowway.com>]

In another post a couple of months ago (see 
https://lists.debian.org/debian-user/2014/07/msg00592.html) I gave some
recommendations for optimal PuTTY settings for use with Debian hosts.
I'd like to follow up on that based on recent discoveries that I have made.

One of the things I recommended was setting the terminal type string to
xterm-utf8.

   Connection -> Data -> Terminal type string : xterm-utf8

(This is a case-sensitive setting.)  I have discovered some color problems
with this terminal type.  In particular, the "--color=auto" option of the "ls"
command behaves sub-optimally.  In wheezy, some of the colors, such as
red, don't display.  In an up-to-date jessie system, no color output occurs
at all.  I decided to investigate this.  The problem is in the "dircolors"
command, which belongs to the "coreutils" package.  In ~/.bashrc, one
finds logic similar to this:

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    .
    .
    .
fi

The line beginning with "test" causes the color definitions stored in
~/.dircolors to be used, if the file exists.  Otherwise it invokes the
"dircolors" command without a filename to set the color definitions
from an internal database.  The result is to set the LS_COLORS
environment variable.  dircolors has an internal database of which
terminal types support color and which don't.  For a terminal type
that supports color, the environment variable LS_COLORS gets set
to a big long string that defines colors.  For a terminal type that
does not support color, LS_COLORS gets set to the null string.  The
problem is that xterm-utf8 is not listed in the dircolors internal
database of terminal types that support color.  It should be.  This
is a bug in dircolors.  As a result, LS_COLORS gets set to the null
string.  In wheezy, if LS_COLORS is the null string, the ls command
with the --color=auto option nevertheless attempts to use a few
basic colors.  This is apparently a bug that has been fixed in
up-to-date jessie systems.  In up-to-date jessie systems, if
LS_COLORS is the null string, ls with the --color=auto option uses
no color at all.

Is there a way around this problem?  Yes, there is.  One way is to
obtain the package source code, add the missing terminal type to
the database, and recompile the package.  If you go this route, the
file to look for is src/dircolors.hin.  Add the line

TERM xterm-utf8

following the last TERM entry in the file, which is currently

TERM xterm-debian

then recompile the package.  After recompiling, install the package
with dpkg.  I won't include instructions for making modifications
to debian source packages in this post.  The advantage to this method
is that making one change in one place fixes the problem for all users.
The disadvantage is that you must be the system administrator
to fix it.

There is another way around the problem.  This method involves
fooling dircolors into thinking that the terminal type is actually
another terminal type, one that it knows supports color.  Change the
above code segment from ~/.bashrc to something like this:

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    # xterm-utf8 is colorizable.
    if [ x$TERM = xxterm-utf8 ];then tempterm=xterm;else tempterm=$TERM;fi
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(TERM=$tempterm dircolors -b)"
    unset tempterm
    alias ls='ls --color=auto'
    .
    .
    .
fi

The above code change causes the dircolors command to see a
TERM value of xterm-utf8 as if it were xterm, without affecting
the permanent value of the environment variable TERM.  Since
xterm is in the database of colorizable terminal types, the
LS_COLORS environment variable will then be set properly.
The advantage of this method is that you can fix the problem for
yourself, even if you are not a system administrator.  If you use
this method as a system administrator, you must edit the ~/.bashrc
file for all your users, plus edit the /etc/skel/.bashrc file to fix
the problem for new users that are subsequently added to the
system.

I'd also like to pass along the following tip from Jochen Spieker
regarding the use of PuTTY with GNU screen.  (See
https://lists.debian.org/debian-user/2014/07/msg01018.html.)
When using PuTTY with GNU screen and terminal type xterm-utf8,
add the following line to ~/.screenrc:

termcapinfo xterm* 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l'

Many people have the above line in this file without the asterisk
after xterm.  The asterisk causes the line to match any terminal
type which starts with xterm.

I hope these tips help someone.

-- 
  .''`.     Stephen Powell    <zlinuxman@wowway.com>
 : :'  :
 `. `'`
   `-