X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=dWFddpHULF1nLW2F
	HaYJsGVdpM0sa+VRqcJfmZvJbjq9ei6D+v0rKfofh1XSOAQq8cOz3tgPLLGPR/l8
	yxNOo/4kRK7qWEEhfef4km/9TnOEChd9EvqKUuGeEME+6Vd/hOtGyjjHRjXp528x
	d7+X59Hi+oWyQKDD3xural4ysk0=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=aiFvwi2aISUrFjrgyg/yoc
	59ajw=; b=uE6Ig0DOojARgNOo8X9zqeU9BMZ5IzDhkEUc/SOT+ILNkixITupv4G
	t8DeqRvoIls7u0CWH1xdIULAewc29FaFWL3sacecNVLhVCk2bbZ8Kv15rvmCtbGK
	rOyq0iXVYvSwdLbDghqyTijX5Zghurn7zHlls9zx+0YYo2yfiOx8g=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=-3.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=downloaded, pty, evidence, View
X-HELO:	rgout0701.bt.lon5.cpcloud.co.uk
X-OWM-Source-IP:	31.51.206.148 (GB)
X-OWM-Env-Sender:	jonturney AT btinternet DOT com
X-VadeSecure-score:	verdict=clean score=0/300, class=clean
X-SNCR-VADESECURE:	CLEAN
Subject:	Re: Regression (last snapshot)
To:	Ken Brown <kbrown AT cornell DOT edu>,
	The Cygwin Mailing List <cygwin AT cygwin DOT com>
References:	<20190722164509 DOT GG21169 AT calimero DOT vinschen DOT de> <eb8007691b20df0eb8032ca3d2fa445f AT smtp-cloud8 DOT xs4all DOT net> <b3b04db5-7f03-8281-f376-6cd10207ec01 AT cornell DOT edu> <4b59209a91e8384ec000e2724696791c AT smtp-cloud7 DOT xs4all DOT net> <935d8ce5-fd5c-3010-4664-bb2dc9b7ca2f AT cornell DOT edu> <20190729084552 DOT GL11632 AT calimero DOT vinschen DOT de> <eea273ca-f190-c91a-7892-9407bfcf4326 AT cornell DOT edu> <20190729134700 DOT GO11632 AT calimero DOT vinschen DOT de> <ced2750a-0a52-1396-b6c1-f4228116bde7 AT cornell DOT edu> <20190729152327 DOT GQ11632 AT calimero DOT vinschen DOT de> <20190729154049 DOT GR11632 AT calimero DOT vinschen DOT de> <c5d01965-80b9-cece-54d2-f7462f84c0a2 AT cornell DOT edu> <8e57d4da-722d-1b9a-bd28-5f96ed182f6a AT cornell DOT edu> <0a09679b-1a0f-613b-04c8-1a63da8a00c2 AT cornell DOT edu>
From:	Jon Turney <jon DOT turney AT dronecode DOT org DOT uk>
Message-ID:	<33aead20-540c-ee3b-0d38-ff053fbac040@dronecode.org.uk>
Date:	Thu, 1 Aug 2019 15:27:32 +0100
User-Agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version:	1.0
In-Reply-To:	<0a09679b-1a0f-613b-04c8-1a63da8a00c2@cornell.edu>

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

- Raw text -