Newsgroups: comp.unix.programmer
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: popen ...
Message-ID: <1991Jun22.162129.723@thunder.mcrcim.mcgill.edu>
Organization: McGill Research Centre for Intelligent Machines
References: <1991Jun20.004507.17814@menudo.uh.edu>
Date: Sat, 22 Jun 91 16:21:29 GMT
Lines: 29

In article <1991Jun20.004507.17814@menudo.uh.edu>, svec5@menudo.uh.edu (T.C. Zhao) writes:

> I have read the popen man page many times, but still do not quite
> understand how it should behave. Consider the following code:

>        if(!(fp = popen("more","w"))
>          fp = stdout;
>        lots_of_output_using_fprintf(fp...)_fputs(..,fp)_with_error_check
>        if(fp!=stdout) pclose(fp);

> everything seems working ok except when more quits prematurely(q),
> the program exits.

Actually, it receives a SIGPIPE signal, which, if uncaught, kills it.
If you block or ignore SIGPIPE, the write() call made by stdio will
return EPIPE, which will cause stdio to return errors - which you
probably aren't checking for, which may or may not be the right thing.
Or you can catch SIGPIPE, instead of blocking or ignoring it, and deal
with it however you want.

(The SIGPIPE signal arises because your program writes on a pipe that's
no longer connected to anything, 'cause the process it used to be
connected to is gone.)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu