Jeff Rodriguez < XXXX@XXXXX.COM > writes:
Well, popen() uses fork and exec too. I would put it a different way,
and say that if the standard popen() doesn't meet your needs, you may
need to code a custom version that does what you want.
Why are you worrying about this? The only process on a Unix system
that isn't created by a fork/exec, is init. popen() uses fork/exec,
and so does system().
You need to decide whether bi-directional communication is a requirement.
If it is, then you should first determine whether the standard popen()
will support that. Some OS's (e.g. Solaris, FreeBSD) have pipes that allow
bi-directional communication, and others (e.g. Linux) don't.
If you need bi-directional communication, then you will definitely need to
do a custom popen(), since you will need separate pipes for the child process's
stdin and stdout.
If you wish to avoid threads and instead monitor multiple child processes
using select(), then there is another issue, which is that popen() provides
a buffered IO stream (FILE *) rather than a file descriptor. You will need
the file descriptor for select(). You can get the underlying file descriptor
using fileno(), and you can make it non-blocking for use with select() via
fcntl(). But you need to be very careful if you are mixing buffered IO
(fread, fscanf, etc. ) with select(), since select doesn't know whether
there is data in the buffer.
I would start with standard popen(), and see how far I got with that.
You may find that popen() doesn't provide any advantages compared to
system(), or you may find that you need to customize popen() for your