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
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
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 s
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 nor
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 thr
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. Th
