Date: Sat, 28 Jun 2008 22:34:06 -0700 (PDT) From: Mike Brown <mike@hyperreal.org> To: freebsd-questions@freebsd.org Subject: Re: null bytes after ANSI sequences in color 'ls' output Message-ID: <20080629053406.82876.qmail@hyperreal.org> In-Reply-To: <20080629002831.GA26661@saltmine.radix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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=vt100-color ESC[36mMailESC[39;49mESC[mESC[m^@^@^@^@^@^@^@^@ with TERM=xterm-color (or just xterm; they're aliases): ESC[36mMailESC[39;49mESC[m^O with TERM=linux: ESC[36mMailESC[39;49mESC[0;10m 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080629053406.82876.qmail>