«

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,
--
John Forkosh ( mailto: where j=john and f=forkosh )

In article <fd0pr1$s1v$>,
JohnF <> wrote:
>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() .
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

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

> In article <fd0pr1$s1v$>,
> JohnF <> wrote:
>>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.
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

Walter Roberson <> wrote:
> JohnF <> wrote:
>>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() .

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: where j=john and f=forkosh )

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

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: where j=john and f=forkosh )

On 23 Sep, 16:09, JohnF <jo...@please.see.sig.for.address.com> wrote:
> 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: j...@f.com where j=john and f=forkosh )

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