Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
I am aware of what Patrick wrote: freopen(3) essentially closes the file descriptor associated with the stream. SO, you can use this to connect stdout to a file. The FILE structure is simply a C data structure. The underlying file is always represented by a file descriptor. So, what freopen does is to close(2) the open file descriptor, open(2) a new one associated with the pathname and associates that with the existing FILE structure. The problem is how the user can communicate things to a running program. Here's a scenario, which I think was presented: 1. start the program, let it run in the background. 2. log out. 3. log back in, and capture the output. The simple solution without program mods is just to let the program write to a file and use tail with the -f option to monitor the output. You can log in and out many times this way. So, you need to invent a way to tell the running program where to send its output (you can use one of many methods, such as signals, files, SystemV message queues, System V shared memory, or even mmap. If you want it to direct output to the current terminal then simply give it the name of the pseudo terminal. Most of this is pretty basic programming techniques. "Derek D. Martin" wrote: > I'm unfamiliar with a lot of the more advanced uses of GDB, but in > addition to the author's response, I can think of one more case where > I believe this will not work: where there are no streams involved. > > freopen() opens a file, and reassociates the stream given as the last > argument with that file. If the file was opened with open(), there is > no stream to associate. > > What I'm not clear on is whether or not some trickery can be done to > do fdopen() followed by freopen(). If this is possible, it might > work. But I don't know how one would take the resulting stream > pointer (from the call to fdopen()) and pass it to the subsequent call > to freopen()... First off, the pointer would (I think) have to > already exist in the program space, which is probably unlikely, or in > many cases impossible to determine. Secondly, whatever value it > contained would have to be irrelevant to the rest of the execution of > the program, since you're going to modify it. Then, maybe, you could > pass it as an argument to freopen()... Yes? > > > - -- > Derek Martin ddm at pizzashack.org > - --------------------------------------------- > I prefer mail encrypted with PGP/GPG! > GnuPG Key ID: 0x81CFE75D > Retrieve my public key at http://pgp.mit.edu > Learn more about it at http://www.gnupg.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8/pHYdjdlQoHP510RAsD9AJ4xknfNpuiU31k0XdjmxmW+E9bCgACdHvyp uTUL1QCPkitSu4wDsuL54Xc= > =DIJ1 > -----END PGP SIGNATURE----- > _______________________________________________ > Discuss mailing list > Discuss at blu.org > http://www.blu.org/mailman/listinfo/discuss > -- Jerry Feldman <gaf at blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |