On Sat, Jun 28, 2008 at 10:34:06PM -0700, Mike Brown wrote:
OK, so the null bytes are correct for vt100 and should've always been there,
and the fact that they've suddenly showed up in FreeBSD 6.3 is basically a
feature.
Setting NCURSES_NO_PADDING has no effect, so 'ls' apparently does
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
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
On Sat, Jun 28, 2008 at 03:16:21PM -0500, Dan Nelson wrote:
In the last episode (Jun 28), Thomas Dickey said:
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
OK, so the null bytes are correct for vt100 and should've always been there,
and the fact that they've suddenly showed up in FreeBSD 6.3 is basically a
feature.
Setting NCURSES_NO_PADDING has no effect, so 'ls' apparently does just use
termcap features.
Following Dan Nelson's advice to switch
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.
