null bytes after ANSI sequences in color 'ls' output
Mike Brown
mike at hyperreal.org
Sat Jun 28 03:13:59 UTC 2008
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.
If I use 'ls -G | less -R', then the ANSI sequences pass through as they
should, but I still get the nulls.
Questions:
Is this is reproducible?
Should I file a PR?
FWIW, my tcsh TERM environment variable is vt100-color.
I'm using SecureCRT with vt100 emulation and ANSI color.
Thanks,
Mike
More information about the freebsd-questions
mailing list