From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; MSIE 6.0; Windows; U; AIIEEEE!; Win98; Windows 98; en-US; Gecko masquerading as IE; should it matter?; rv:1.8b) Gecko/20050217 Description of problem: The papd application fails to correctly close pipe. Version-Release number of selected component (if applicable): netatalk-2.0.2-3 How reproducible: Always Steps to Reproduce: 1.read source file papd/lp.c 2. 3. Actual Results: See that fclose is always invoked, even if it is a pipe. Expected Results: Should be possibly using pclose. Additional info: From pclose manual entry: "The return value from popen() is a normal standard I/O stream in all respects save that it must be closed with pclose() rather than fclose()"
Created attachment 121427 [details] Corrects fclose on pipe
I'm not sure this is a good idea. Closing the stream unconditionally with fclose() means that the reader process will get a broken pipe error, ie. it knows that papd is finished with it. pclose() on the other hand "waits for the associated process to terminate" (man popen(3)) before closing the stream and returns the process exit status . Perhaps lp programs could depend on the broken pipe error to know when input is finished; if papd used pclose, it could wait forever for the reader to terminate. There is no value in using pclose() rather than fclose() if you do not want to wait for the program at the other end of the pipe to terminate. Does this use of pclose fix any definite, reproducible problem ? If so, please re-open this bug with details of how to reproduce, and I'll contact the upstream maintainers to get their opinion on this issue.
(In reply to comment #2) > I'm not sure this is a good idea. That is an interesting conclusion. And an interesting discusssion about why pclose() might not be a good idea. Now, let's have a look at the glibc code for pclose: int __new_pclose (FILE *fp) { return _IO_new_fclose (fp); } Do you see what I can see?