redirect system() stdout to buffer

J

JohnF

I'd like to capture the stdout output from system("command")
in a buffer. Although system("command >tmpnam") and then
open,read,remove tmpnam works, it's a bit more messy than
I'd like. Is there any way to redirect system()'s stdout
directly to an internal memory buffer before issuing the call?
Thanks,
 
W

Walter Roberson

I'd like to capture the stdout output from system("command")
in a buffer. Although system("command >tmpnam") and then
open,read,remove tmpnam works, it's a bit more messy than
I'd like. Is there any way to redirect system()'s stdout
directly to an internal memory buffer before issuing the call?

Not within Standard C. Recall that *all* the C standards say
about the interpretation of the system() command is that
you can probe for the -existance- of an interpreter by passing
the NULL pointer: otherwise, what happens about the string is
completely system dependant.

If you are assuming that the system() command has a mechanism
for producing some kind of useable output, then you are making
a non-portable assumption, and so you might as well go ahead and
add in some kind of more blatant non-portability that does the
job you need. For example, if you are on a system with POSIX
extensions, you could (at no loss of portability since what you
want to do is non-portable anyhow) use popen() .
 
A

Army1987

Not within Standard C. Recall that *all* the C standards say
about the interpretation of the system() command is that
you can probe for the -existance- of an interpreter by passing
the NULL pointer: otherwise, what happens about the string is
completely system dependant.

If you are assuming that the system() command has a mechanism
for producing some kind of useable output, then you are making
a non-portable assumption, and so you might as well go ahead and
add in some kind of more blatant non-portability that does the
job you need.
There are different systems where system("foo > bar") executes
foo placing its output in bar. One might write code portable
across those but not elsewhere. "Either portable everywhere or
useful on only one architecture" is a false dilemma (look up
Wikipedia). (Anyway, I can not think of a way to do what the OP
wants on all those systems, so, if he only wants to support one
architecture, he should ask in a group about it.)
 
J

JohnF

Walter Roberson said:
Not within Standard C. Recall that *all* the C standards say
about the interpretation of the system() command is that
you can probe for the -existance- of an interpreter by passing
the NULL pointer: otherwise, what happens about the string is
completely system dependant.

If you are assuming that the system() command has a mechanism
for producing some kind of useable output, then you are making
a non-portable assumption, and so you might as well go ahead and
add in some kind of more blatant non-portability that does the
job you need. For example, if you are on a system with POSIX
extensions, you could (at no loss of portability since what you
want to do is non-portable anyhow) use popen() .

Thanks, Walter, ditto Army1987.
Looks to me like popen() will work fine. I'm basically
concerned about Unix and Windows. And a little googling seems
to suggest most Windows compilers support popen(), though there
appear to be a few obscure differences in behavior that
someone or other occasionally tripped over.
Thanks, again, for bringing popen() to my attention.
 

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,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top