From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75642 invoked by alias); 1 Aug 2019 14:27:40 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 75635 invoked by uid 89); 1 Aug 2019 14:27:40 -0000 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 Received: from rgout0701.bt.lon5.cpcloud.co.uk (HELO rgout0701.bt.lon5.cpcloud.co.uk) (65.20.0.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Aug 2019 14:27:38 +0000 X-OWM-Source-IP: 31.51.206.148 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-SNCR-VADESECURE: CLEAN Received: from [192.168.1.102] (31.51.206.148) by rgout07.bt.lon5.cpcloud.co.uk (9.0.019.26-1) (authenticated as jonturney@btinternet.com) id 5C6509360F327384; Thu, 1 Aug 2019 15:27:35 +0100 Subject: Re: Regression (last snapshot) To: Ken Brown , The Cygwin Mailing List References: <20190722164509.GG21169@calimero.vinschen.de> <4b59209a91e8384ec000e2724696791c@smtp-cloud7.xs4all.net> <935d8ce5-fd5c-3010-4664-bb2dc9b7ca2f@cornell.edu> <20190729084552.GL11632@calimero.vinschen.de> <20190729134700.GO11632@calimero.vinschen.de> <20190729152327.GQ11632@calimero.vinschen.de> <20190729154049.GR11632@calimero.vinschen.de> <8e57d4da-722d-1b9a-bd28-5f96ed182f6a@cornell.edu> <0a09679b-1a0f-613b-04c8-1a63da8a00c2@cornell.edu> From: Jon Turney Message-ID: <33aead20-540c-ee3b-0d38-ff053fbac040@dronecode.org.uk> Date: Thu, 01 Aug 2019 14:27:00 -0000 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> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-08/txt/msg00007.txt.bz2 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