redirecting stdout

K

Kenny McCormack

Of course i'm interested.

OK - I'll see if I can dig it up. I need to find an old disk image and see
if it is still there.
Here is the best i can do, based on all the remarks here (still no
posting in comp.unix.programming, as i did some research and reading
instead):

Yaknow... And FWIW, and all that...

It just occurred to me, why not just use "freopen()"?
Something like:

freopen("/tmp/mytmpfile","w",stdout);
// Invoke whatever things generate output on stdout
// Now read /tmp/mytmpfile into memory, parse it, do whatever you need to.
// (And then unlink() the file)

This is not quite as cool as having it write directly to memory, but it is
pretty simple to implement.
 
T

Tim Rentsch

Tim Rentsch said:
It looks like popen() does what you want, ...

No.

Please re-read. [snip]

Quoting the person I was responding to (and who started the
thread), whose comment you snipped:

I don't see any reason for anyone to believe you have a better
understanding of what he is trying to do than he does. If and
when he has something to say in response to my remarks, I shall
consider what further response might be appropriate at that
time. And he is welcome to email me directly at the above
address if he might prefer that.
 
G

glen herrmannsfeldt

(snip)
It just occurred to me, why not just use "freopen()"?
Something like:
freopen("/tmp/mytmpfile","w",stdout);
// Invoke whatever things generate output on stdout
// Now read /tmp/mytmpfile into memory, parse it, do whatever you need to.
// (And then unlink() the file)
This is not quite as cool as having it write directly to
memory, but it is pretty simple to implement.

Back when I used to use SunOS (pre-Solaris), they had device
mapped memory. That is, a /dev entry that, when opened, would
read form or write to memory. (fseek() is very useful here.)

Also, the more usual memmap for memory mapped files, along with
the devices allowed one to map memory to memory. In the specific
case, we could map some part of VME address space (VME has a lot of
different address space) to user memory, allowing for easy use
of VME cards with memory mapped I/O or on-board buffers.

I don't know if current systems do that, though.

-- glen
 
P

Phil Carmody

jseb said:
Hello,


I'd like to bufferise stdout. That's it, when something is sent to
stdout FD, it goes instead to a buffer.

(it's for sending this buffer to another computer with network sockets).

I read that "open_memstren" could do that (posix function).

Here is my test:


///////////// CODE START /////////////////

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

int main(void)
{
char *buffer; //for open_memstream
size_t size;
FILE *memstream = open_memstream(&buffer, &size);

int stdout_copy = dup(1); //save stdout

stdout = memstream; //redirection

Can you even do that? stdout isn't necessarily an lvalue, is it?

And do you even want to do that - shouldn't you close stdout first?

Phil
 
K

Kenny McCormack

Of course i'm interested.

OK - I finally got around to unearthing that old code that I wrote.

The idea is that you have a process (program) that generates output on
stdout and you want to capture that in buffer (i.e., a string), without
having to re-write any of the code that generates it. I.e., as far as the
process is concerned, it *is* writing to stdout. Note that the stdout
generating process may be any combination of puts, printf, etc.

Here's the code:

EXPORT char *mp3_info(int argc,char **argv,int olen,char *obuff,int elen,char *ebuff)
{
static char buff[30];
int ret;

setvbuf(stdout,obuff,_IOFBF,olen);
setvbuf(stderr,ebuff,_IOFBF,elen);
optind = 1;
ret = main(argc,argv);
obuff[olen = stdout -> _cnt ? olen - stdout -> _cnt : 0] = 0;
ebuff[elen = stderr -> _cnt ? elen - stderr -> _cnt : 0] = 0;
sprintf(buff,"%d,%d,%d",ret,olen,elen);
return buff;
}

Explanation:
1) This is a Windows DLL, hence the "EXPORT".
2) It is called from a program written in a scripting language; so the actual
return value is a string containing "ret", "olen", and "elen". This
detail need not concern us in the instant context.
3) The caller passes in the argc and argv values which are then passed to
"main" to do the actual work. The caller also passes in buffers and
lengths for stdout and stderr, which are captured independently.

Tell me what you think...
 
J

James Kuyper

One of the larger problems with this approach is:

Which approach?

I know the faulty reasons that you have given for not providing proper
attribution of quoted remarks (and, as always, I refuse permission to
quote my text without proper attribution). However, responding to
something without even quoting it isn't the solution.
 
K

Kenny McCormack

One of the larger problems with this approach is:

foo.c: error: 'FILE' has no member named '_cnt'

although it might work on the particular platform you are interested in.

Of course. I made it entirely clear that this was a very platform-specific
approach - and the OP seemed OK with that.

It's based on, as I noted in my original post to this thread, "cracking
open stdio.h" and figuring it out. Obviously, you may have to re-do that
effort to get it to work on another platform (compiler, toolchain, etc).

But it works - and that, as they say, is the important thing.

--
But the Bush apologists hope that you won't remember all that. And they
also have a theory, which I've been hearing more and more - namely,
that President Obama, though not yet in office or even elected, caused the
2008 slump. You see, people were worried in advance about his future
policies, and that's what caused the economy to tank. Seriously.

(Paul Krugman - Addicted to Bush)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,754
Messages
2,569,522
Members
44,995
Latest member
PinupduzSap

Latest Threads

Top