jik@athena.mit.edu (Jonathan I. Kamens) (04/30/91)
(Note: comp.lang.c is not relevant to this discussion. Popen() is not in the ANSI C spec, and is not a C thing, it's an OS-dependent thing. The people in comp.lang.c get a little upset when people start talking about OS-dependent functions in that newsgroup.) In article <174@shasta.Stanford.EDU>, shap@shasta.Stanford.EDU (shap) writes: |> popen(3) also has an interesting "feature." It is essentially useless |> unless the program you run from it doesn't read from stdin. Here's |> why. |> |> ... |> |> 2. Child program (the filter) processes some input and writes |> results to it's output (which the parent will eventually |> read). Um, because of the deadlock problems you describe, peopen was specifically designed to allow only one channel through which the parent can talk to the child -- either the parent writes to the child and the child sends its output to stdout, or the parent reads from the child and the chid gets its input from stdin. Yes, you can circumvent this, by playing games with stdout and stdin, but if you do that, then you deserve to lose, and it is *you* who are introducing the problem, not popen. So it is completely inaccurate to say that, when using popen, the parent can send output to the child and the parent will eventually read the child's output in response. That's not popen. This is all addressed in question number 26 in the comp.unix.questions Frequently Asked Questions posting, which even says where to get source code for a set of routines that allows you to do two-way communication with a child process without deadlock problems. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710