Determining EOF character

[Daniel Klein]

On Sun, 18 Feb 2001 18:44:21 -0800, Tim Roberts <timr at probo.com> wrote:

>Daniel Klein <danielk at aracnet.com> wrote:
>
>>On Sun, 18 Feb 2001 11:35:41 -0800, Erik Max Francis <max at alcyone.com> wrote:
>>
>>>Daniel Klein wrote:
>>>> On Windows the child process needs to send a ^Z in response to
>>>> readlines() and
>>>> on UNIX it needs to send ^D. I don't know what this is on MAC.
>>>
>>>This isn't the way you should signal end of file.  You should signal it
>>>the client closing his end of the pipe.  In fact, what you suggest above
>>>may work on Windows, but it won't work on UNIX -- under UNIX, an end of
>>>file isn't indicated with a sentinel character in the stream, but rather
>>>with an out-of-bounds indicator (the underlying file structure has an
>>>end-of-file flag).
>>
>>I'm not sure what you mean by "You should signal it the client closing his end
>>of the pipe". This is an interactive session with the client and server in
>>constant communication. If I close the pipe, I can do no further processing.
>
>I don't understand.  If the character you're waiting for doesn't terminate
>the connection, then why use an O/S-dependent character at all?  Why not
>just choose some arbitrary control character specific to your application.

I don't want to terminate the connection, I only want to know when the server
(child) process has stopped sending. If I terminate (close) the connection, the
server process becomes orphaned.

Here is a simple scenario of what I am trying to do:  Python (the parent
process) starts the child process with 'popen2.popen'. Let's assume that the
file handles are called 'instream' and 'outstream'.

1) parent sends a request to the child via outstream

2) child stdin receives the request and performs some action which results in a
variable number of lines (say less than 10) of output which are sent to stdout.

3) parent receives the lines via instream, analyzes the lines for it's next
action. Go to step 1.

This interaction should be continuous until the parent process sends a 'quit'
command to the child, at which point the child shuts itself down and the parent
proceeds to close both handles (instream and outstream).

If the client and server were only sending one line at a time, it would be
simple to do with readline() and write():

1) parent send line
2) child recv line
3) child send line
4) parent recv line
5 go to 1)

But, as illustrated above, the server (child) process can sometimes send more
than one line and it is not possible to determin in advance how many lines. To
be honest, the server process _does_ know how many lines it is sending except
when an error occurs. It is these errors that produce an indeterminate number
of lines which get sent back to the parent (child stdout --> parent instream).

On Windows, all I need to do is send a ^Z to indicate (end of transmission).

Dan