Regression (last snapshot)

[Jon Turney]

On 31/07/2019 19:00, Ken Brown wrote:
> On 7/31/2019 11:53 AM, Ken Brown wrote:
>> On 7/29/2019 2:55 PM, Ken Brown wrote:
>>> Here's the error that I can reproduce easily in xterm:
>>>
>>> $ ls <(grep bash .bashrc)
>>> /dev/fd/63
>>> grep: write error: Broken pipe
>>>
>>> This happens 98% of the time.  Notice that I used plain 'ls' rather than the
>>> original 'ls -lL'.  With the latter, I get the broken pipe error 60% of the time
>>> rather than 98%:
>>>
>>> $ ls -lL <(grep bash .bashrc)
>>> pr-------- 1 kbrown None 0 2019-07-29 14:46 /dev/fd/63
>>> grep: write error: Broken pipe
>>>
>>> What about the explanation I tried earlier, but perhaps not clearly: ls prints
>>> /dev/fd/63 and then exits, thereby closing the read end of the pipe, while grep
>>> (running asynchronously) hasn't finished writing to the write end of the pipe.
>>>
>>> The fact that I get the broken pipe error more often with plain 'ls' than with
>>> 'ls -lL' is consistent with that.  And the fact that I get no errors with 'cat
>>> <(grep bash .bashrc)' is also consistent with it, since cat doesn't exit until
>>> grep has finished writing.
>>>
>>> On the other hand, this doesn't explain why I see the error only under xterm,
>>> nor does it explain why you can't reproduce it at all.
>>
>> I've made some progress.  It turns out that the problem only occurs in terminals
>> launched from the xwin-xdg-menu tray icon.  I can even launch a mintty window
>> from that icon (System Tools -> Cygwin Terminal) and I'll see the problem.  On
>> the other hand, I can launch an xterm without using that icon (e.g., 'DISPLAY=:0
>> xterm -l&' from a mintty window) and I won't see the problem.
>>
>> So the issue has something to do with how xwin-xdg-menu launches applications,
>> and how that interacts with bash's process substitution.  I've just downloaded
>> the xwin-xdg-menu source and will see if I can figure out what's going on.  I've
>> also added Jon to the CC in case he has a chance to take a look.
> 
> 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.  For
> example, here's what I see when I launch mintty from xwin-xdg-menu:
> 
> $ pgrep mintty
> 5375
> 
> $ ls -l /proc/5375/fd
> total 0
> lrwxrwxrwx 1 kbrown None 0 2019-07-31 13:37 0 -> /dev/null
> lrwxrwxrwx 1 kbrown None 0 2019-07-31 13:37 1 -> pipe:[38654736160]
> lrwxrwxrwx 1 kbrown None 0 2019-07-31 13:37 2 -> pipe:[42949703456]
> lrwxrwxrwx 1 kbrown None 0 2019-07-31 13:37 3 -> /dev/ptmx
> lrwxrwxrwx 1 kbrown None 0 2019-07-31 13:37 4 -> /dev/windows
> 
> These pipes are apparently used for logging.

That's correct.  Writes to those pipes are drained into the session 
logfile (~/.xsession-errors), which you can view with the 'View logfile' 
menu item.

> I don't see how this would explain my observations (grep reporting a broken
> pipe), but it is at least a difference between a terminal started from
> xwin-xdg-menu and an "ordinary" terminal.
> 
> Anyway, I don't see any evidence here of a Cygwin bug.

I'm not so sure: these pipes for stdout/stderr of the mintty process 
shouldn't have any influence at all on the child bash process (since 
it's stdin/stdout/stderr is the slave end of a pty), but apparently they 
somehow do?

--
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