From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53894 invoked by alias); 24 Feb 2020 14:46:41 -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 53883 invoked by uid 89); 24 Feb 2020 14:46:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.1 spammy=inherited, studio, ship, Studio X-HELO: mail-ed1-f46.google.com Received: from mail-ed1-f46.google.com (HELO mail-ed1-f46.google.com) (209.85.208.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Feb 2020 14:46:29 +0000 Received: by mail-ed1-f46.google.com with SMTP id r21so12190482edq.0 for ; Mon, 24 Feb 2020 06:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WLu5AFs2bQC/KkhpefEbams2YN+hBFQJHdk1g5/fgh8=; b=ncECB4TEY5IevfDZal+s26zq9fqxyKCtTJOiVBN4ik8Hjq2+uW/2QNkSFkrF8X5od9 nkoIKiyVd/HhjMtVA/Br/+MLtIhNRNCzvpyHnjt0rtedFB5Y0JMZ9hDTHOTuk03aeUtr Eds2dcAV3l29EAscpNn8r4Y/RmmZ476H12Subh3GyDmsNia/EGRb5dwgj+Z3pEaieUUI EoZ/lejU+s/UfJ8gbZA0/m0M+CQLE48dur0MTyXC6pt++GOmhv9MmPvDR517uHIsJVje tNksUCqOddtEuBTguardBERy4YuxLb+36+Lb2nlVZNA17ShSPRuoMf5xsgMgIYpBcZ5w vXuQ== MIME-Version: 1.0 References: <20200131072536.da46ccf9cb52b1afdefa2a9a@nifty.ne.jp> <20200219044302.bd24ffa7af1f159c67583600@nifty.ne.jp> <20200221100121.44625484e94eef069f9ff3d8@nifty.ne.jp> In-Reply-To: <20200221100121.44625484e94eef069f9ff3d8@nifty.ne.jp> From: Edward Lam Date: Mon, 24 Feb 2020 14:46:00 -0000 Message-ID: Subject: Re: Pipes bug when spawning non-cygwin processes To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00224.txt.bz2 Hi, Thank you for your reply. On Thu, Feb 20, 2020 at 8:01 PM Takashi Yano wrote: > Thanks for the test case. Indeed, this works upto cygwin 3.0.7, > and does not work in cygwin 3.1.0 or later. > > However, I wonder what platform is your program for. This test > case does not work also in native windows command prompt. > Your test case works only in old cygwin pty. > I have a native graphical Windows application that relied on cygwin/mintty providing stdout so that my printf's work. I would contend that there's no reason for cygwin/mintty to work the same as the native windows command prompt because the behaviour there is for it to detach the child process. This is not the case when we run a graphical process in a cygwin/mintty shell. The old behaviour was much welcome because it allowed graphical applications that did not detach from the console work just like on Linux. I should note that there is also the odd behaviour that the child process is created with an inherited stderr handle but when I try to write to it, it doesn't show up anywhere. On the native windows command prompt, the child process isn't even created with the inherit handles flag enabled. If you want to make a program which works in cygwin pty, you > can use cygwin g++ like: > g++ -mwindows pipes.cpp -o pipes > The binary built by above command works in cygwin pty, but does > not work in cygwin console (cygwin in command prompt) even with > cygwin 3.0.7. > This might not have worked in cygwin 3.0.07 because it's missing a freopen("CONOUT$", "w", stdout). I had omitted this in my minimal test case because I found that this was unnecessary when I built with Visual Studio. If you want to make a program which works with windows console, > you should change the code like: > > INT WinMain(HINSTANCE, HINSTANCE, PSTR, INT) > { > if (!AttachConsole(ATTACH_PARENT_PROCESS)) AllocConsole(); > freopen("CONOUT$", "w", stdout); > printf("This message used to show up in mintty cygwin v.2.11.2 shell! > or from ssh session\n"); > return 0; > } > Ah, I did not now about AttachConsole(ATTACH_PARENT_PROCESS). The application that I ship out to my users cannot force the requirement of having cygwin, nor is compiling with cygwin g++ an option. Is there some way to have a non-cygwin app detect the presence of cygwin pty so that it can behave differently? When the native command prompt detaches the child process, the child process should not really write to the parent's console and should allocate its own instead. Thanks again, -Edward -- 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