VanDyke Software Forums

VanDyke Software Forums (
-   SecureCRT 5.1/SecureFX 3.1/VShell 2.6 Beta (
-   -   Minor glitch in 256-color xterm emulation (

ErnieLongmire 03-23-2005 12:29 PM

Minor glitch in 256-color xterm emulation
In Beta 2 I'm seeing a minor glitch when running the xterm test script "" (Google for links). ^[[48;5;124m displays as rgb(175,0,0) instead of rgb(127,0,0), and ^[[48;5;64m displays as rgb(95,135,0) instead of rgb(42,85,0). (Values are slightly different in the GIF below but you can see the cells with the problem.)

mistwolf 03-23-2005 04:26 PM

Odd, I see it here OK.

ErnieLongmire 04-29-2005 12:01 PM

For what it's worth, I'm still seeing this glitch in build 871. Let me know if there's anything I can provide to help track this down.

Maureen 05-02-2005 04:48 PM

Thanks for following up on this. What terminal emulation and font are you using? Could you please post your script?


ErnieLongmire 05-16-2005 02:51 PM


Originally Posted by Maureen
Thanks for following up on this. What terminal emulation and font are you using? Could you please post your script?

Maureen -- I'm using Xterm emu, ANSI color selected. Font is Bitstream Vera Sans Mono Regular 10. When I switch to Courier New and run again, the new output is correct. When I switch back to Bitstream Vera Sans Mono and the screen redraws with the new font, the original output is redrawn with the correct colors. When I run one more time, the output is also correct.

Here's the script:


# Author: Todd Larason <>
# $XFree86: xc/programs/xterm/vttests/,v 1.1 1999/07/11 08:49:54 dawes Exp $

# use the resources for colors 0-15 - usually more-or-less a
# reproduction of the standard ANSI colors, but possibly more
# pleasing shades

# colors 16-231 are a 6x6x6 color cube
for ($red = 0; $red < 6; $red++) {
    for ($green = 0; $green < 6; $green++) {
        for ($blue = 0; $blue < 6; $blue++) {
                  16 + ($red * 36) + ($green * 6) + $blue,
                  int ($red * 42.5),
                  int ($green * 42.5),
                  int ($blue * 42.5));

# colors 232-255 are a grayscale ramp, intentionally leaving out
# black and white
for ($gray = 0; $gray < 24; $gray++) {
    $level = ($gray * 10) + 8;
          232 + $gray, $level, $level, $level);

# display the colors

# first the system ones:
print "System colors:\n";
for ($color = 0; $color < 8; $color++) {
    print "\x1b[48;5;${color}m  ";
print "\x1b[0m\n";
for ($color = 8; $color < 16; $color++) {
    print "\x1b[48;5;${color}m  ";
print "\x1b[0m\n\n";

# now the color cube
print "Color cube, 6x6x6:\n";
for ($green = 0; $green < 6; $green++) {
    for ($red = 0; $red < 6; $red++) {
        for ($blue = 0; $blue < 6; $blue++) {
            $color = 16 + ($red * 36) + ($green * 6) + $blue;
            print "\x1b[48;5;${color}m  ";
        print "\x1b[0m ";
    print "\n";

# now the grayscale ramp
print "Grayscale ramp:\n";
for ($color = 232; $color < 256; $color++) {
    print "\x1b[48;5;${color}m  ";
print "\x1b[0m\n";

jcj 05-18-2005 04:42 PM

ErnieLongmire -

I'm not seeing this behavior. I'm using Beta 5, so if you haven't given it a try yet, you might want to download it from:

Using Bitstream Vera Sans Mono, with xterm emulation with ANSI color enabled, I get the expected output from .

Are you consistently able to reproduce this with Beta 5 ?

Please let us know.


ErnieLongmire 03-06-2006 12:11 PM

Still seeing this...!
I've updated my installation to 5.1.0 Build 254 and for some reason I'm still seeing this color-cube glitch. Any suggestions on how I can help you debug this?

jjh 03-07-2006 01:57 PM

Hello Ernie.

I tried to reproduce the problem that you are seeing, but I
haven't been able to. I have created an entry for you in
our bug tracking database for our developers to review. We
will contact you when we have something for you to try.

Thank you


ErnieLongmire 05-03-2006 07:50 PM

I think I've solved this, or at least figured out what's causing it. It looks like under certain circumstances, SCRT will lose a character while processing the escape sequence that loads a color into Xterm's 256-color index table:

ESC ] 4 ; index ; rgb:rval/gval/bval ESC \

When that happens, the default color value for that table position remains unchanged, which can show up as an unexpected color value as shown in the screencap I posted earlier. This happens for me in SCRT versions up through 5.1.0 build 263.

Here's another script that shows the bug for me pretty consistently:


#!/usr/bin/perl -w

printf "before\n\n"; &show_colors;
printf "press enter to load replacement color table: ";
readline(*STDIN); &load_colors;
printf "after\n\n"; &show_colors;
printf "\x1b[39m\x1b[49m\n\n";

sub load_colors {
  for (my $i = 16; $i <= 255; $i++) {
    printf "\x1b]4;%d;rgb:%2.2x/%2.2x/%2.2x\x1b\\", $i, $i, $i, $i;
    printf "\x1b[38;5;%dm%d: %2.2x/%2.2x/%2.2x\n", $i, $i, $i, $i, $i;

sub show_colors {
  for (my $bgix = 0, $fgix = 255; $bgix <= 255; $bgix++, $fgix--) {
    printf "\x1b[48;5;%dm\x1b[38;5;%dm**", $bgix, $fgix;
    if (! (($bgix+1) % 16)) { print "\x1b[48;5;0m\x1b[38;5;255m\n"; }
  printf "\x1b[0m\n";

What'll usually happen is that while it's loading the color table (and printing each value as it's loaded) I'll get a couple of output glitches like these:

203: cb/cb/cb
204: cc/cc/cc
;205;rgb:cd/cd/cd205: cd/cd/cd
206: ce/ce/ce
207: cf/cf/cf

with the result that color position 80 keeps its default value, which shows up when the new color table is used.

After running the script you can reset the color table with Edit > Reset from SCRT's menu bar.

Please let me know if this helps you reproduce the behavior.

Marlow Weston 05-04-2006 09:09 AM

We have tried both scripts with your particular font and a clean restart of the application to no avail. :confused:

At this point we would like to view your session.ini and global.ini files to find what terminal settings you are using. Could you please send these files to me at with the subject of ATTN: Marlow Forum Thread 617?

Thank you,
Marlow Weston

ErnieLongmire 05-04-2006 12:58 PM

Sent. Thanks, Marlow.

All times are GMT -6. The time now is 07:09 PM.