Command substitution and daemons - Request for help

[Mark Rosenthal]

In article <257 at aoa.UUCP> I asked for help with a background process
which outputs to stdout and then computes forever.  I was trying to
use backquote evaluation to assign the output of the process to a
shell variable, but the shell appeared to hang during the evaluation.

It turns out to be the result of my failing to close stdout.  I enclose
herewith one of the responses I received.  Many thanks to all who responded.  
BTW, as John suggests, I too was bitten by this in my days as a fledgling
Unix programmer.  Guess I should have seen it myself.  But then, what
is the net for?  Also, thanks to everybody for responding by mail rather
than adding to the already immense load on usenet.

John Macklin writes:
>
> I have to admit that it took me a few minutes to work out the answer
> to your problem.  I'm ashamed, I should have known at once, but this
> is truly ``old wine in a new bottle'' -- I think almost every serious
> UNIX systems programmer must have been bitten by this exactly once in
> his/her career, BUT in a very different guise.  Usually you see it the
> first time you try to make significant use of pipes.  You're doing that
> here but it's well hidden and takes a while to spot.
> 
> The Answer (no, not 42):
> 
> A process which reads a pipe will not see EOF on the pipe as long
> as ANY OTHER PROCESS has the write end of the pipe open.
> 
> So, in your case, the shell will keep reading the pipe it created
> to be dmn's standard output, due to the fact that dmn's child still
> has the write end of the pipe open.  The shell cannot know that there
> isn't more output coming.  The fix is simple, just do a close(1) in
> the child after you fork.
> 
> John Mackin, Basser Department of Computer Science,
> 	     University of Sydney, Sydney, Australia
-- 

	Mark of the Valley of Roses
	...!{decvax,linus,ima,ihnp4}!bbncca!aoa!mbr