Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mit-eddie!ll-xn!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!unido!fauern!faui44!mlelstv From: mlelstv@faui44.informatik.uni-erlangen.de (Michael van Elst ) Newsgroups: comp.sys.amiga.tech Subject: Re: Is there a preferred way to do popen()? Message-ID: <601@faui44.informatik.uni-erlangen.de> Date: 18 Aug 88 10:46:29 GMT References: <618@super.ORG> Reply-To: mlelstv@faui44.UUCP (Michael van Elst) Organization: CSD., University of Erlangen, W - Germany Lines: 33 In article <618@super.ORG> rminnich@metropolis.super.org (Ronald G Minnich) writes: >Those of you who looked at the ucompat.c file i shipped out last week >probably noticed that among others popen was a no-op. I have not >the faintest idea of how to make this work on Amigados without bringing >in P:, PIPE:, or some other non-standard hack. > Am i missing something? Is there a way to do popen(), within the >bounds of a straight workbench 1.2? Hmm, you say PIPE: is a non-standard hack ? I know of several good pipe handlers that work. Anyway, it is difficult to write a popen() function that matches the UNIX implementation of pipes. popen() returns two filehandles that can both be used for input and for ouput. In usual one task then closes input and the other closes ouput. In AmigaDOS you have to determine which of the two file handles is for input and which of them is for output as no pipe-handler that I know of has the ability of writing to the input side and vice versa. Another possibility for pipes (or at least pipy behaviour) is the clipboard.device. You can POST data blocks (that are not copied) and Wait until someone has read your block. You may exit your program, then the device copies your buffer to disk so that the other task can read it even then. Michael van Elst E-mail: UUCP: ...seismo!unido!fauern!faui44!mlelstv E-mail: UUCP: ...uunet!unido!fauern!faui44!mlelstv <- when seismo ceases operation