c++: Run process and get stdout into string-variable
Florian Erfurth
and get its output (stdout). Now I have to write a program without
QT-library. Unfortunatelly I don't know how to do that. I read about
exec(), fork(), system(), popen() but I don't understand how to do that
with C++. :( Could anyone of you point to a good howto (respective small
excample)?
Thank you very much!
cu Floh
John
Look at popen
Wolfgang Draxinger
create two pipes with pipe(...), one for stdin, one for stdout.
You could also redirect stderr, but usually stderr is meant for
messages that should not be redirected.
fork(...) the process.
in the child process (the one where fork(...) returns 0) dup
(...) the pipes to stdin/stdout.
exec[v][e] the to be started programm file in the child process.
In the parent process (the one where fork) returns the PID of the
child) do a loop that reads from the child's stdout (
select(...) or poll(...), read(...) ) into a buffer, until the
child terminates ( waitpid(...) ). Eventually supply the child
with input on stdin if it expects some.
When done close(...) the pipes.
man 2 pipe
man 2 fork
man 2 dup2
man 2 waitpid
man 2 select
man 2 poll
man 2 read
man 2 close
Wolfgang Draxinger
--
E-Mail address works, Jabber: hexa...@jabber.org, ICQ: 134682867
Rainer Weikusat
> Florian Erfurth wrote:
>> Hi how can I do that? In the past I used QProcess from QT to
>> run a process and get its output (stdout). Now I have to write
>> a program without QT-library. Unfortunatelly I don't know how
>> to do that. I read about exec(), fork(), system(), popen() but
>> I don't understand how to do that with C++. :( Could anyone of
>> you point to a good howto (respective small excample)?
>>
>> Thank you very much!
>
> create two pipes with pipe(...), one for stdin, one for stdout.
An alternative to creating two pipes would be a pair for connected
PF_UNIX stream sockets created by a call to socketpair.
Florian Erfurth
> Florian Erfurth wrote:
>
>> [Question: See subject]
>
> create two pipes with pipe(...), one for stdin, one for stdout.
> You could also redirect stderr, but usually stderr is meant for
> messages that should not be redirected.
That is ok.
> fork(...) the process.
>
> in the child process (the one where fork(...) returns 0) dup
> (...) the pipes to stdin/stdout.
>
> exec[v][e] the to be started programm file in the child process.
>
> In the parent process (the one where fork) returns the PID of the
> child) do a loop that reads from the child's stdout (
> select(...) or poll(...), read(...) ) into a buffer, until the
> child terminates ( waitpid(...) ). Eventually supply the child
> with input on stdin if it expects some.
Um... you're talking about child and parent process. But... I only need the
one process. The other process is my program itself, which should run a
process and get the output.
If I understand what you did write, I should start 2 processes (parent and
child)?
cu Floh
Rainer Weikusat
This means your program is the parent and the program it started would
be the child.
Wolfgang Draxinger
> Um... you're talking about child and parent process. But... I
> only need the one process. The other process is my program
> itself, which should run a process and get the output.
> If I understand what you did write, I should start 2 processes
> (parent and child)?
No, I wrote you should fork() your process. Fork will split your
process into two, a parent process (the one you'd refer as your
program) and a child process. If you'd only fork without doing
anything else you end up with two copies of your program running
in parallel, having the same file descriptors open etc. They do
not however share address space (fork() does not spawn a thread,
clone() does that). The only difference is the return value of
fork. The parent process gets the child's pid back, the child
gets 0 back. Usually the child then calls exec which will
replace it's process structure with the one of another
executable.