Re: null bytes after ANSI sequences in color 'ls' output
On Sat, Jun 28, 2008 at 10:34:06PM -0700, Mike Brown wrote: 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. yes - in responding, I saw that while I'd implemented NCURSES_NO_PADDING for just the curses library, it could be made to work with termcap. But that's not addressing your immediate question, which Dan did. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpV9uY2WBo7h.pgp Description: PGP signature
Re: null bytes after ANSI sequences in color 'ls' output
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;[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ 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). 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. 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpuSYZyT3rbg.pgp Description: PGP signature
Re: null bytes after ANSI sequences in color 'ls' output
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;[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ 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 [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: null bytes after ANSI sequences in color 'ls' output
On Sat, Jun 28, 2008 at 03:16:21PM -0500, Dan Nelson wrote: In the last episode (Jun 28), Thomas Dickey said: 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. yes (xterm wouldn't have padding ;-) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp34LjsS2EcF.pgp Description: PGP signature
Re: null bytes after ANSI sequences in color 'ls' output
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[foom
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;[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL
PROTECTED]@
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.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
null bytes after ANSI sequences in color 'ls' output
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;[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
