Returned mail: User unknown

[Mail Delivery Subsystem]

   ----- Transcript of session follows -----
>>> RCPT To:<//@score.stanford.edu>
<<< 550 No such local mailbox as "//", recipient rejected
550 //@SCORE.STANFORD.EDU... User unknown

   ----- Unsent message follows -----
Received: by Forsythe.Stanford.EDU; Sat, 19 Mar 88 12:36:31 PST
Received: by BYUADMIN (Mailer X1.25) id 7069; Sat, 19 Mar 88 13:36:55 MST
Date:         Sat, 19 Mar 88 14:00:13 CST
Reply-To: Unix-Wizards at BRL.ARPA
Sender: Unix-Wizards Mailing List <UNIX-WIZ%NDSUVM1.BITNET at Forsythe.Stanford.EDU>
From: Vince Fuller <VAF at score.stanford.edu>
Subject:      Obscure UNIX question
X-To:         UNIX-WIZARDS at BRL.ARPA, INFO-UNIX at BRL.ARPA
To: //@SCORE.STANFORD.EDU

I am attempting to write an application that will talk to a child process via
a PTY. I want to make this communication as completely half duplex as possible,
e.g. my program sends a command string to the PTY then reads the response and
processes it. Because I do not have control over the format of the output from
the child process and it is safe to assume that it is synchronous (i.e. it
reads its input, generates some output, then reads some more input), I want to
be able to read output from the PTY until the child blocks for input. Is there
any way for me to detect that the child process has done this (blocked for
input)? My groveling about in the UNIX manual pages for pty(4), tty(4), et. al.
hasn't gotten me anywhere. Alternatively, if it is not possible to do what I
want, can someone suggest an alternative method to write this application? In
summary, what I want to do is two step loop in the parent process:

    1) Send command to child process by writing on master end of PTY.
    2) Read and process child's output by reading from master end of PTY until
       child is finished processing the command. The child is considered to be
       "finished" when it blocks for input while reading from the slave end of
       PTY - this is the state that I need to be able to detect.

    Thanks,
    Vince Fuller, Stanford Networking Systems
-------
-------