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;[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL > > PROTECTED]@[EMAIL PROTECTED]@ > > > > 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 [EMAIL PROTECTED] _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"