Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!uvaarpa!mcnc!decvax!purdue!i.cc.purdue.edu!j.cc.purdue.edu!ags
From: ags@j.cc.purdue.edu (Dave Seaman)
Newsgroups: comp.lang.lisp
Subject: Re: Is LISPcraft mistaken?
Message-ID: <6356@j.cc.purdue.edu>
Date: 4 Feb 88 17:07:00 GMT
References: <11022@shemp.UCLA.EDU>
Reply-To: ags@j.cc.purdue.edu.UUCP (Dave Seaman)
Organization: Purdue University
Lines: 37

In article <11022@shemp.UCLA.EDU> krowney@MATH.UCLA.EDU (Kevin Rowney) writes:
 [describing apparent problem with interprocess communication in Franz]

>1) lisp
>Franz Lisp, Opus 38.92
>-> ;Fire up and get ports to a "wc" process.
>(setq ports (*process 'wc t t))
>(%from-process %to-process 6550)

>-> ;Feed the running "wc" some input
>(mapc '(lambda (x) (print x (cadr ports))) '(a b c d))
>(a b c d)

So far, everything is correct.

>-> ;Read any results that might have come back
>(read (car ports))

This got no response because wc was still waiting for more input or for
an indication that the end of the standard input has been reached.
Therefore you need to

-> (close (cadr ports)) 

before attempting to read.  Note that this is special to ``wc''.  Not all
processes insist on reading all of their input before producing any
output.

>Also note that I have tried doing a (patom (ascii 4) (cadr ports)) [that is
>tossing a ^D to the process in order to tell it the input is done] with the 
>same results.  

Since the input to wc is not a terminal device, wc sees the ^D as an
ordinary ASCII character and obediently counts it.  You need to close the
pipe to indicate end of input.
-- 
Dave Seaman	  					
ags@j.cc.purdue.edu