redirect system() stdout to buffer

[JohnF]

I'd like to capture the stdout output from system("command ")
in a buffer. Although system("command >tmpnam") and then
open,read,remov e 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,
--
John Forkosh ( mailto: [e-mail] where j=john and f=forkosh )

[Walter Roberson]

In article <fd**********@r eader1.panix.co m>,
JohnF <jo***@please.s ee.sig.for.addr ess.comwrote:

>I'd like to capture the stdout output from system("command ")
in a buffer. Although system("command >tmpnam") and then
open,read,remo ve 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() .
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[Army1987]

On Fri, 21 Sep 2007 16:22:07 +0000, Walter Roberson wrote:

In article <fd**********@r eader1.panix.co m>,
JohnF <jo***@please.s ee.sig.for.addr ess.comwrote:

>>I'd like to capture the stdout output from system("command ")
in a buffer. Although system("command >tmpnam") and then
open,read,rem ove 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.

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.)
--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes� feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

[JohnF]

Walter Roberson <ro******@ibd.n rc-cnrc.gc.cawrote :

JohnF <jo***@please.s ee.sig.for.addr ess.comwrote:

>>I'd like to capture the stdout output from system("command ")
in a buffer. Although system("command >tmpnam") and then
open,read,rem ove 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() .

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.
--
John Forkosh ( mailto: [e-mail] where j=john and f=forkosh )

[stephenwvickers]

Although /off-topic/ you may find it is named _popen() on Windows.

[JohnF]

st************* @googlemail.com wrote:

Although /off-topic/ you may find it is named _popen() on Windows.

Terrific. Another #ifdef for Windows.
Just what I wanted.
--
John Forkosh ( mailto: [e-mail] where j=john and f=forkosh )

[stephenwvickers]

On 23 Sep, 16:09, JohnF <jo...@please.s ee.sig.for.addr ess.comwrote:

stephenwvick... @googlemail.com wrote:

Although /off-topic/ you may find it is named _popen() on Windows.

Terrific. Another #ifdef for Windows.
Just what I wanted.
--
John Forkosh ( mailto: [e-mail] where j=john and f=forkosh )

Come on, you wouldn't expect anything else would you? :-)