On 8/1/2019 12:04 PM, Corinna Vinschen wrote: > On Aug 1 10:38, Eric Blake wrote: >> On 8/1/19 10:30 AM, Ken Brown wrote: >> >>>>> OK, when xwin-xdg-menu launches an application, it creates two pipes >>>>> and sets >>>>> the application's stdout and stderr to the write ends of those pipes. >> >>> Well, I can't be sure that the pipes are responsible. It's just that >>> the existence of the pipes is the only difference I could spot between >>> an ordinary terminal and a terminal started from xwin-xdg-menu. >>> >>> Is it possible that the logging somehow slows things down or changes the >>> buffering, so that the grep process takes longer to complete? This >>> would be consistent with my theory that the broken pipe error doesn't >>> really represent a bug, but rather it reflects the fact that ls exits >>> before grep has finished writing. >> >> Could it be a case of xwin-xdg-menu calling signal(SIGPIPE, SIG_IGN) or >> similar, and accidentally letting grep inherit the ignored SIGPIPE? > > execve doesn't propagate the signal dispositions, they get reset to > default.
I just realized, as a result of Eric's comment, that the explanation I've been pushing is nonsense. What I've been explaining is why there would be a broken pipe, and therefore a SIGPIPE and EPIPE. But I now see that that's not the issue. The issue is whether grep gets the SIGPIPE and terminates before it has a chance to see the EPIPE. So if grep isn't ignoring SIGPIPE, the only other possibility I can think of is that grep isn't receiving SIGPIPE, or at least that there's a delay before it receives it. Why would that happen only in terminals started by xwin-xdg-menu? Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple