Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Jun 2008 07:39:57 -0400
From:      Thomas Dickey <dickey@radix.net>
To:        Mike Brown <mike@hyperreal.org>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: null bytes after ANSI sequences in color 'ls' output
Message-ID:  <20080628113957.GA25335@saltmine.radix.net>
In-Reply-To: <20080628024552.81805.qmail@hyperreal.org>
References:  <20080628024552.81805.qmail@hyperreal.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=
=20
> colorized 'ls -G' output is now plagued with 8 null bytes following each =
ANSI=20
> sequence.
>=20
> I normally pipe my output to 'less -R' so ANSI sequences pass through whi=
le=20
> other control characters are converted to visible ones. This worked great=
=20
> 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.
>=20
> For example, I'm getting output like this if I use 'ls -G | less':
>=20
> ESC[36mMailESC[39;49mESC[mESC[m^@^@^@^@^@^@^@^@
>=20
> It's the '^@'s that are unexpected, although the repeated ESC[m pairs are=
 also=20
> 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).

Real vt100's require padding (emulators generally do not ;-).

That's the termcap, looking at a not-very-recent copy.

If your terminal description came in part from terminfo, ncurses'
terminfo for vt100 has padding for several features, which can be
disabled for curses apps by setting NCURSES_NO_PADDING in the
environment.

However, I suspect that "ls" is just using termcap features, so that
environment variable may have no effect (depends on what "ls" does
with the termcap string, to write it to the terminal).

But it's something to check/try.
=20
> If I use 'ls -G | less -R', then the ANSI sequences pass through as they=
=20
> should, but I still get the nulls.
>=20
>=20
> Questions:
>=20
> Is this is reproducible?
> Should I file a PR?
>=20
> FWIW, my tcsh TERM environment variable is vt100-color.
> I'm using SecureCRT with vt100 emulation and ANSI color.=20
>=20
> Thanks,
> Mike
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.o=
rg"

--=20
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--9jxsPFA5p3P2qPhR
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQFIZiMLtIqByHxlDocRAhV/AJsHCosCY4SRF50+37MR4SsrJWpQ3gCfaXdl
oKH84K0tKxwf+n70wAONHUI=
=1WtF
-----END PGP SIGNATURE-----

--9jxsPFA5p3P2qPhR--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080628113957.GA25335>