Xref: utzoo comp.unix.sysv386:1694 gnu.misc.discuss:1922 comp.lang.c:33300 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!uokmax!rmtodd From: rmtodd@uokmax.ecn.uoknor.edu (Richard Michael Todd) Newsgroups: comp.unix.sysv386,gnu.misc.discuss,comp.lang.c Subject: Re: Does GNU's C Compiler Have a Full Screen Debugger? Message-ID: <1990Oct31.031227.20715@uokmax.ecn.uoknor.edu> Date: 31 Oct 90 03:12:27 GMT References: <54@bmhalh.UUCP> Distribution: gnu Organization: Engineering Computer Network, University of Oklahoma, Norman, OK Lines: 26 eru@tnvsu1.tele.nokia.fi (Erkki Ruohtula) writes: >The only CodeView-feature I miss in gdb+emacs is the separate screen for >program output that prevents program I/O and debugger commands from mixing >(perhaps the gdb mode could be hacked to use a separate Emacs buffer >for debugger I/O?). There's a *really sleazy* way to route the output of your program to a different window that I've used on occasion. It works only under X Window, and is a really cheap hack; no doubt someone can suggest a better way. Here goes: 1. Start up an xterm. This xterm window will eventually be used for the program's output. When you get a shell prompt, type "tty; sleep 10000" This will print out the device name (/dev/ttyp?) of the pty for that xterm, then sleep for hours and hours (meaning you won't have the shell of that xterm trying to read from the same tty we'll have our program doing I/O on). 2. In another window (either xterm or Emacs), start up gdb on your program. Before doing the 'run', issue the command tty /dev/ttyp? where "/dev/ttyp?" is the name of the tty you got in step 1. Now, all I/O your program does will be on that tty, hence in that xterm window, and all communication with the debugger will be in the original window. Sleazy, but it works.... -- Richard Todd rmtodd@chinet.chi.il.us or rmtodd@uokmax.ecn.uoknor.edu "MSDOS is a Neanderthal operating system" - Henry Spencer