emacs gdb subproccess ignores printf (stdout isn't flushed ?) on OS X

emacs gdb subproccess ignores printf (stdout isn't flushed ?) on OS X

[Mike Garey]

I've noticed that when using gdb under the carbon (Apple OS X) version
of GNU Emacs 21.3.50.1, printf statements are not printed until after
the program has terminated, even though the print statements contain a
newline.  I can force them to print by modifying my source and adding
"fflush(NULL);" after each printf statement, but I'd like to find out
how to avoid this.

I compiled this version from the 21.3.50.1 CVS source as of Dec 30th,
2004.  I'm thinking that perhaps I might've missed some compile flag
or something?  Because I've tested with the fink version 21.3.50.1 and
it works without issue, and also with version 21.2.1 which comes with
Panther.  So it's only this self compiled version that's giving me
problems.

I would gladly switch back to a previous carbon version, however,
there's a problem with lisp.el which prevents sexp-selections from
being extended, and it's a feature I need.  This has been addressed by
21.3.50.1, although like I said, gdb printf statements don't produce
immediate output.  So ideally I'd like to find out how to fix this
problem with 21.3.50.1

While we're on the subject of using gdb from within emacs, I'm curious
if there's any way to suppress the following control characters when
using gdb:

^[^[[0K(gdb) 
^[^[[2A
^[^[[0Khello, world!

I've set --annotate=1, and I don't receive any control characters
while single stepping, it's only when printing that I receive the
characters as mentioned above (the ^[[0K and such).  And of course
this doesn't happen with version 21.3.50.1, since I can't even get my
printf lines to show output.

So if anyone has any suggestions, please let me know, I'd really
appreciate it.  Thanks,

Mike

P.S. I'm using GNU gdb 5.3-20030128 (Apple version gdb-330.1) with
Panther (10.3.4) on a G4 iBook 800mhz if that makes any difference.

Re: emacs gdb subproccess ignores printf (stdout isn't flushed ?) on OS X

[Peter Dyballa]

Am 20.02.2005 um 20:17 schrieb Mike Garey:

> I've noticed that when using gdb under the carbon (Apple OS X) version
> of GNU Emacs 21.3.50.1, printf statements are not printed until after
> the program has terminated, even though the print statements contain a
> newline.  I can force them to print by modifying my source and adding
> "fflush(NULL);" after each printf statement, but I'd like to find out
> how to avoid this.

Hello!

Could you check process-connection-type? Is it nil, i.e.communication 
via pipes? Then try it with this:

         (setq process-connection-type t)

This makes shell work correct too!

--
Greetings

   Pete

The mathematician who pursues his studies without clear views of this 
matter, must often have the uncomfortable feeling that his paper and 
pencil surpass him in intelligence. (Ernst Mach)

suppressing gdb subprocess control characters? (was Re: emacs gdb subproccess ignores printf (stdout isn't flushed ?) on OS X)

[Mike Garey]

Thanks for the help Peter, setting process-connection-type to true worked.

I should also mention that after I sent the message to the list, I
downloaded and compiled the newest CVS source (GNU Emacs 22.0.50.1),
and it seemed to fix the problem as well (without the need to setq
process-connection-type t).  Although, strangely enough, with the
newest CVS version, I no longer get a red dot representing a
breakpoint under the gdb subprocess.. I'm sure there's probably just
some setting I need to change to get this to work.

I'm still curious as to how to suppress the strange control characters
printed by gdb, such as:

^[[2A
^[[0Khello, world!

since it'd be a lot easier to read output without seeing these odd
characters.  Thanks again for the help!

Mike

P.S. I've tried setting the gdb annotation level to 1 to remove the
control characters, and while it removes some of them, the ones above
still remain (although they only appear when executing a printf
statement it seems).  I'm thinking it might have something to do with
the buffer-coding-system setting?


On Sun, 20 Feb 2005 23:51:20 +0100, Peter Dyballa <Peter_Dyballa@web.de> wrote:
> 
> Am 20.02.2005 um 20:17 schrieb Mike Garey:
> 
> > I've noticed that when using gdb under the carbon (Apple OS X) version
> > of GNU Emacs 21.3.50.1, printf statements are not printed until after
> > the program has terminated, even though the print statements contain a
> > newline.  I can force them to print by modifying my source and adding
> > "fflush(NULL);" after each printf statement, but I'd like to find out
> > how to avoid this.
> 
> Hello!
> 
> Could you check process-connection-type? Is it nil, i.e.communication
> via pipes? Then try it with this:
> 
>          (setq process-connection-type t)
> 
> This makes shell work correct too!
> 
> --
> Greetings
> 
>    Pete
> 
> The mathematician who pursues his studies without clear views of this
> matter, must often have the uncomfortable feeling that his paper and
> pencil surpass him in intelligence. (Ernst Mach)
> 
>

Re: suppressing gdb subprocess control characters? (was Re: emacs gdb subproccess ignores printf (stdout isn't flushed ?) on OS X)

[Peter Dyballa]

Am 21.02.2005 um 00:08 schrieb Mike Garey:

> ^[[2A
> ^[[0Khello, world!

gdb or Emacs or both think they're running in a DEC terminal or such, 
so they're sending ANSI escape codes to it to position the text 
somewhere on the terminal's screen, or to set it bold, blinking, ...

Since I haven't used gdb for so many years I actually have no idea -- 
have you seen the invisible directory .MacOSX in you home directory? It 
contains a file environment.plist. To edit it you'll need some of the 
Developer Tools, the Property List Editor, in 
/Developer/Applications/Utilities. Just type in Terminal (or Carbon 
Emacs) "open ~/.MacOSX/environment.plist" and it'll appear. Now you 
could add a new environment variable TERM and give it the value emacs, 
or dumb. But be careful: some applications might fail after a new login 
(that's needed to make the new setting/sibling active)!

A less dangerous setting would be in the gdb section. AFAIR you can 
trim its run-time environment. Maybe here's a choice to set the 
TERMinal value to something dumb, something that can't be controlled by 
ANSI escape sequences. Just read a bit of the documentation!

--
Greetings

   Pete

One doesn't expect governments to obey the law because of some
higher moral development.  One expects them to obey the law because
they know that if they don't, those who aren't shot will be hanged.
                                                  --Michael Shirley