null bytes after ANSI sequences in color 'ls' output

Mike Brown mike at
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 
termcap features.

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, 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=vt100-color

with TERM=xterm-color (or just xterm; they're aliases):

with TERM=linux:

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 mailing list