From owner-freebsd-questions@FreeBSD.ORG Sun Jun 29 05:34:12 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57C60106564A for ; Sun, 29 Jun 2008 05:34:12 +0000 (UTC) (envelope-from mike@hyperreal.org) Received: from hyperreal.org (taz3.hyperreal.org [209.237.226.90]) by mx1.freebsd.org (Postfix) with SMTP id 4BD298FC12 for ; Sun, 29 Jun 2008 05:34:12 +0000 (UTC) (envelope-from mike@hyperreal.org) Received: (qmail 82877 invoked by uid 1001); 29 Jun 2008 05:34:06 -0000 Message-ID: <20080629053406.82876.qmail@hyperreal.org> In-Reply-To: <20080629002831.GA26661@saltmine.radix.net> To: freebsd-questions@freebsd.org Date: Sat, 28 Jun 2008 22:34:06 -0700 (PDT) Sender: mike@hyperreal.org From: Mike Brown X-Whoa: whoa. X-Mailer: ELM [version 2.4ME+ PL123e (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Subject: Re: null bytes after ANSI sequences in color 'ls' output X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2008 05:34:12 -0000 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[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.