null bytes after ANSI sequences in color 'ls' output
mike at hyperreal.org
Sun Jun 29 05:34:12 UTC 2008
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
Setting NCURSES_NO_PADDING has no effect, so 'ls' apparently does just use
Following Dan Nelson's advice to switch TERM to xterm-color only changes the
behavior slightly: rather than getting 2 trailing ESC[m sequences followed by
8 null bytes, I get 1 ESC[m followed by a single 0x0F byte, which shows up as
"^O" when piped through less.
After reading a bit more about ANSI codes at
http://bjh21.me.uk/all-escapes/all-escapes.txt, I see that the trailing codes
are just variations on a 'reset' theme.
ESC[36m = cyan text
ESC[39;49m = default text; default background
ESC[m = same as ESC[0m
ESC[0m = default rendition, canceling any preceding ESC[<foo>m
ESC[0m;10m = default rendition; default font
Ctrl-O in xterm = string command/capability 'ae' ('End alternative character set')
Now, I thought I'd try terminal type 'linux' as well. This changes things a
bit: I now get ESC[0;10m at the end, which means reset to default rendition,
with the default font. It has no padding bytes or odd control chars, so I can
use this with 'less -R'.
In summary, 'ls -dG Mail | less' yields the following:
with TERM=xterm-color (or just xterm; they're aliases):
So I guess as long as I use 'less -R', which is the only way to reliably use
'less' to page ANSI color output, I'm going to have to use TERM=linux, or else
add another pipe to filter out the offending characters, like 'tr -d "\000"'.
I think I'm going to opt for the latter, for now, because I seem to recall
some weirdness with SecureCRT's linux emulation.
Thanks for the speculation and assistance! You got me on the right track.
More information about the freebsd-questions