null bytes after ANSI sequences in color 'ls' output

[Dan Nelson]

In the last episode (Jun 28), Thomas Dickey said:
> On Fri, Jun 27, 2008 at 07:45:52PM -0700, Mike Brown wrote:
> > After I upgraded 6.2-STABLE (Feb 2007-ish) to 6.3-STABLE (last
> > week), my colorized 'ls -G' output is now plagued with 8 null bytes
> > following each ANSI sequence.
> > 
> > I normally pipe my output to 'less -R' so ANSI sequences pass
> > through while other control characters are converted to visible
> > ones. This worked great until now. Now I see '^@' for each null.
> > It's not a new feature of less, so I assume it's ls or curses
> > throwing in the nulls.
> > 
> > For example, I'm getting output like this if I use 'ls -G | less':
> > 
> > ESC[36mMailESC[39;49mESC[mESC[m^@^@^@^@^@^@^@^@
> > 
> > It's the '^@'s that are unexpected, although the repeated ESC[m
> > pairs are also mysterious since they seem to have no purpose.
> 
> It's possible that an application could be sending padding characters
> (nulls).  The vt100-color terminal description inherits from vt100,
> which does use padding - but in the sf/sr (scroll forward/reverse).

If that's the case, then the easy fix would be to tell SecureCRT to
emulate am xterm instead, and set the terminal type to xterm-color. 
You would probably get better function key mappings, too.

> > FWIW, my tcsh TERM environment variable is vt100-color.
> > I'm using SecureCRT with vt100 emulation and ANSI color.

-- 
	Dan Nelson
	dnelson at allantgroup.com