douglas@dcc1.UUCP (Douglas B. Jones) (04/05/86)
Hi,
In the routine popen(3), a program can open either a read pipe
or a write pipe to a sub-process (usually a program, like more).
Does any one have a similar routine that will allow a person to
have a read/write pipe to a sub-process. The routine might have
the following format:
FILE *wfp, /* stdin to child */
*rfp, /* stdout from child */
*refp; /* stderr from child */
int p,
popen2();
void pclose2();
if ((p = popen2("program",wfp,rfp,refp)) < 0) {
fprintf(stderr,"Can't open pipe to program\n");
exit(1);
}
At this point :
p : index so that pclose2() would know which child to close
wfp : how I write to the childs' stdin,
rfp : the stdout from the child to me,
rwfp: the stderr from the chid to me.
The pclose2() routine would be called:
(void)pclose2(p); /* p being the return from popen2() */
This would be a very helpful program. I imagine it would have
to deal with sockets(). What would be really nice, is if two version
of this popen2() could be written. One to allow the calling program
to work with a child process on the local system, and secondly to
allow it (the calling program) to work with a child process on
another system (in the local network).
Maybe : popen2() for local (with pclose2()) and npopen2() for
remote (withe npclose2()). Npopen2() might have a calling format
like :
/* other vars. stated above */
char *network = "dcc2"; /* name of our other system */
int npopen2();
void npclose2();
if ((p = npopen2("program",wfp,rfp,refp,network)) < 0) {
fprintf(stderr,"Can't open net pipe to program\n");
exit(1);
}
/* do what ever, ie: write UNIX documentation or crash the system */
(void)npclose2(p);
Thanks in advance,
Douglas
p.s.: Apart from sending this to net.wanted.sources, I am also sending
this to net.unix and net.unix-wizards to reach a larger group of
people. Response might best go to net.sources. I will be happy
to handle responses directly and then post them to net.sources.
--
----------------------------------------------------------------------
Douglas Jones
TSG, DeKalb College
douglas@dcc1
gatech!dcc1!douglas { calls us each hour }
akgua!dcc1!douglas { calls us about twice a day }
akgua!gatech!dcc1!douglas { akgua and gatech communicate a lot }
----------------------------------------------------------------------ji@garfield.columbia.edu (John Ioannidis) (04/06/86)
In article <201@dcc1.UUCP>, douglas@dcc1.UUCP (Douglas B. Jones) writes: > > Hi, > > In the routine popen(3), a program can open either a read pipe > or a write pipe to a sub-process (usually a program, like more). > Does any one have a similar routine that will allow a person to > have a read/write pipe to a sub-process. .... > This would be a very helpful program. I imagine it would have > to deal with sockets(). Quite some time ago I had posted to net.unix-wizards my version of a read-and-write popen. It had a slightly different calling sequence, and used pty's instead of either pipes or socketpairs. This has some advantages, like being able to get back prompts from the child process; some programs check isatty(1) and don't output a prompt if it is not. (for example, ftp(1)). Anyway, check older postings for my program. > What would be really nice, is if two version > of this popen2() could be written. One to allow the calling program > to work with a child process on the local system, and secondly to > allow it (the calling program) to work with a child process on > another system (in the local network). > I guess, you can just use /usr/ucb/rsh instead of /bin/sh for the shell in popen or whatever. This also takes care of security; you won't have to implement Yet Another security/user authorization/whatever scheme. Hope all that helps, - john #include <appropriate_disclaimers> VOICE: +1 212 280 5510 ARPA: ioannidis@cs.columbia.EDU USnail: John Ioannidis ji@garfield.columbia.EDU 450 Computer Science Columbia University, USENET: ...{seismo|topaz}! New York, NY 10027 columbia!garfield!ji ... It's all Greek to me!
fair@styx.UUCP (Erik E. Fair) (04/10/86)
The unfortunate problem with this idea is that the possibilities for deadly embrace the two processes involved are numerous. Erik E. Fair styx!fair fair@lll-tis-b.arpa