Colored output of the terminal program is displayed without color, with control sequences visible

[yurivict]

I have a terminal program that senses if the standard output is a terminal (based on isatty(1)), and automatically prints control sequences when it is a terminal.

The problem is that when run under cgdb, for some reason, isatty(1) returns 'true', but output isn't printed as colored, and control sequences are printed as clear text.
When run under just gdb, output is colored.

This test case demonstrates this problem:

#include <unistd.h>
#include <stdio.h>

main() {
  if (isatty(1)) {
    printf("\033\[31mWe are on the terminal, this is a red text\033\[m\n");
  } else {
    printf("We are not on the terminal, this is a black text\n");
  }
}

I run on kde4 konsole terminal, if this matters, on FreeBSD 9.

[brasko]

On Fri, Jul 25, 2014 at 02:37:40PM -0700, yurivict wrote:

I have a terminal program that senses if the standard output is a terminal (based on isatty(1)), and automatically prints control sequences when it is a terminal.

The problem is that when run under cgdb, for some reason, isatty(1) returns 'true', but output isn't printed as colored, and control sequences are printed as clear text.
When run under just gdb, output is colored.

This test case demonstrates this problem:

#include <unistd.h>
#include <stdio.h>

main() {
  if (isatty(1)) {
    printf("\033\[31mWe are on the terminal, this is a red text\033\[m\n");
  } else {
    printf("We are not on the terminal, this is a black text\n");
  }
}

I run on kde4 konsole terminal, if this matters, on FreeBSD 9.

In general, cgdb will not make debugging other terminal programs easy.

If it's possible, you should start your program from the terminal, and
then attach to that program with cgdb from another terminal.

This way your program will have complete access to the terminal and you
can use it in any way that you previously would.

I hope this is helpful. In the future, I might provide better support
for this in CGDB.

Bob Rossi

[yurivict]

I think that cgdb tries to send terminal output to libncurses window, it strips part of the control sequence (0x1b) and this causes this problem. This appears to be a design problem: terminal output shouldn't be sent to the channel that can't accept it.

cgdb should use something 'setupterm' call from libncurses, like tmux does. But this is a major redesign.

[brasko]

On Fri, Jul 25, 2014 at 08:43:36PM -0700, yurivict wrote:

I think that cgdb tries to send terminal output to libncurses window, it strips part of the control sequence (0x1b) and this causes this problem. This appears to be a design problem: terminal output shouldn't be sent to the channel that can't accept it.

cgdb should use something like this: setupterm, like tmux does. But this is a major redesign.

CGDB is going to get lots of major redesigns in the next 6-12 months i
hope. I'll keep this in mind.

Bob Rossi

[brasko]

On Sun, Jul 27, 2014 at 07:39:19AM -0400, Bob Rossi wrote:

On Fri, Jul 25, 2014 at 08:43:36PM -0700, yurivict wrote:

I think that cgdb tries to send terminal output to libncurses window, it strips part of the control sequence (0x1b) and this causes this problem. This appears to be a design problem: terminal output shouldn't be sent to the channel that can't accept it.

cgdb should use something like this: setupterm, like tmux does. But this is a major redesign.

CGDB is going to get lots of major redesigns in the next 6-12 months i
hope. I'll keep this in mind.

The correct thing to do here, might be to have CGDB require tmux for
improved terminal interaction. Then CGDB could spread it's windows
across different tmux windows, and the user could display them however
they want.

I'm posting this here so I'll remember this idea when I get back to it.

Tmux is really good at terminal emulation. This isn't a problem CGDB
should be solving.

Bob Rossi

[crowell]

this is still an issue, is there a reason this is closed?

the problem is with scr_add in scroller.c, I'd be interested in tackling this.

[yurivict]

I think this is still a problem.