From owner-freebsd-questions@FreeBSD.ORG Sat Jun 28 20:16:24 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 27C2B1065680 for ; Sat, 28 Jun 2008 20:16:24 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id DB0A28FC0A for ; Sat, 28 Jun 2008 20:16:23 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.2) with ESMTP id m5SKGLNV000961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 28 Jun 2008 15:16:21 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.2/Submit) id m5SKGLv1000960; Sat, 28 Jun 2008 15:16:21 -0500 (CDT) (envelope-from dan) Date: Sat, 28 Jun 2008 15:16:21 -0500 From: Dan Nelson To: Thomas Dickey Message-ID: <20080628201621.GB4081@dan.emsphone.com> References: <20080628024552.81805.qmail@hyperreal.org> <20080628113957.GA25335@saltmine.radix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080628113957.GA25335@saltmine.radix.net> X-OS: FreeBSD 7.0-STABLE User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-questions@freebsd.org, Mike Brown 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: Sat, 28 Jun 2008 20:16:24 -0000 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 normally pipe my output to 'less -R' so ANSI sequences pass > > through while other control characters are converted to visible > > ones. This worked great until now. Now I see '^@' for each null. > > It's not a new feature of less, so I assume it's ls or curses > > throwing in the nulls. > > > > For example, I'm getting output like this if I use 'ls -G | less': > > > > ESC[36mMailESC[39;49mESC[mESC[m^@^@^@^@^@^@^@^@ > > > > It's the '^@'s that are unexpected, although the repeated ESC[m > > pairs are also mysterious since they seem to have no purpose. > > 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 sf/sr (scroll forward/reverse). If that's the case, then the easy fix would be to tell SecureCRT to emulate am xterm instead, and set the terminal type to xterm-color. You would probably get better function key mappings, too. > > FWIW, my tcsh TERM environment variable is vt100-color. > > I'm using SecureCRT with vt100 emulation and ANSI color. -- Dan Nelson dnelson@allantgroup.com