Path: utzoo!attcan!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!gatech!galbp!wittsend.LBP.HARRIS.COM!mhw
From: mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield (Mike))
Newsgroups: comp.unix.questions
Subject: Re: end of file characters and open file descriptors
Message-ID: <6919@galbp.LBP.HARRIS.COM>
Date: 2 Jan 89 19:30:48 GMT
References: <1345@cod.NOSC.MIL>
Sender: news@galbp.LBP.HARRIS.COM
Reply-To: mhw@wittsend.UUCP (Michael H. Warfield (Mike))
Organization: Harris/Lanier Network Knitting Circle
Lines: 49

In article <1345@cod.NOSC.MIL> waagen@cod.nosc.mil.UUCP (Don E. Waagen) writes:

>   I'm trying to have two processes communicate via a pipe (stdout), like 

>but with a small difference.  Process A will never die (i.e. the connection 
>will never be closed).  What I would like to do is have the fread and getchar()
>calls of process B sense or think that it is seeing the pipe close (i.e. an EOF
>character returned by the calls) without closing the connection.

>I have tried flushing EOT characters (^D) to process B, but this doesn't help.
>The fread call in process B remains blocked.  

>I've also tried having process A's standard out dup'd and then closing standard
>out, and then duping the duplicate back to 1 (standard out); no luck.  It 
>seems the dup'd file descriptors share status fields.

>My Question: What do the standard library calls use to determine end-of-file.
>I really need to be able to do this, for a process to know when an end of 
>transmission has occured.

     Point #1 - There is no "end of file" charracter.  The EOT character is
interpreted (in cooked mode) by the tty device driver and translated into an
end of file on that file descriptor.  In order to get an end of file when
reading a pipe ALL fid's connected with that pipe and open for write must be
closed.  The standard library calls get the end of file status from the system.
i.e. The file system drivers inform the application that you are at end-of-file.

     I can't think of any easy way to signal the reading process of an end-of-
file and still be able to use that pipe later.  Maybe someone in the wizards
group can come up with an idea.  This would seem to have some interesting
possiblilities.

     BTW:  What does process "B" do when it gets the end of file?  Does he
quit?  This would cause a "broken pipe" to process "A".

     If you have source control over both processes, your best bet is probably
to use some sort of "in-band" signaling between the processes.  i.e. A certain
character sequence signals your interprocess "end-of-file" (EOT ^D would work
nice) and then support and escape sequence to transfer a legitimate EOT
charracter (\^D) and one for the escape character (\\).  This requires
filtering all of your data but that may be easier than faking out a real
end-of-file.  If you have to use out-of-band signaling then you probably need to
resort to interprocess signals ala SIG_USR1 and SIG_USR2.

---
Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!