From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9144 invoked by alias); 16 Apr 2019 09:16:21 -0000 Mailing-List: contact cygwin-developers-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com Received: (qmail 9133 invoked by uid 89); 16 Apr 2019 09:16:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-104.3 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,RCVD_IN_DNSWL_NONE,UNSUBSCRIBE_BODY autolearn=ham version=3.3.1 spammy=crazy, screen, H*F:D*cygwin.com, device X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Apr 2019 09:16:19 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MyNoa-1gvKNY3qCy-00ylSf for ; Tue, 16 Apr 2019 11:16:16 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 8AEF4A80742; Tue, 16 Apr 2019 11:16:16 +0200 (CEST) Date: Tue, 16 Apr 2019 09:16:00 -0000 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: [PATCH v5 1/1] Cygwin: pty: add pseudo console support. Message-ID: <20190416091616.GN3599@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <20190412102047.669-1-takashi.yano@nifty.ne.jp> <20190414152316.1468-1-takashi.yano@nifty.ne.jp> <20190414152316.1468-2-takashi.yano@nifty.ne.jp> <20190415083832.GC3599@calimero.vinschen.de> <20190416094143.c612b1d9262bd015a8103f10@nifty.ne.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9/eUdp+dLtKXvemk" Content-Disposition: inline In-Reply-To: <20190416094143.c612b1d9262bd015a8103f10@nifty.ne.jp> User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-04/txt/msg00046.txt.bz2 --9/eUdp+dLtKXvemk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2816 On Apr 16 09:41, Takashi Yano wrote: > On Mon, 15 Apr 2019 10:38:32 +0200 Corinna Vinschen wrote: > > This is supposed to be combined with the preceeding code to a single > > expression in the end, right? >=20 > Do you mean this code and the preceding code should be executed > exclusively? If so, the answer is no. If the stderr is pty slave, > the message should be written to both output_handle and > output_handle_cyg. The reason will be described later. >=20 > > I don't quite understand why writing > > to STD_ERROR_HANDLE doesn't work. Is STD_ERROR_HANDLE not connected > > to the ConPty? >=20 > You are right. STD_ERROR_HANDLE (output_handle) is connected to > the ConPTY. The data written to output_handle is fowarded to > to_master_cyg in the master, then displayed. to_master_cyg is > duplicated to output_handle_cyg in the slave. Therefore, both > writing to output_handle and writing to output_handle_cyg seem > to work, at first glance. >=20 > However, in the fact, the code below stops forwarding if the > process is a cygwin process.=20 > + /* Avoid duplicating slave output which is already sent to > + to_master_cyg */ > + if (!get_ttyp ()->switch_to_pcon) > + continue; >=20 > The role of the code above is as follows. ConPTY sometimes redraws > screen based on its own screen buffer. The screen buffer has only > the data written to output_handle. Basically, cygwin apps use > output_handle_cyg and native apps use output_handle. Terefore, > outputs from cygwin apps are disappeared at that time. To avoid > this, the data write to output_handle_cyg is pushed into the ConPTY > screen buffer by WriteFile() to output_handle. To prevent the data > from being displayed twice, forwarding is stopped by the code above > if the process is a cygwin app. >=20 > In strace.cc, writing to output_handle is necessary for pushing > the data into ConPTY screen buffer, and writing to output_handle_cyg > is necessary for displaying it. Huh, crazy. Thanks for explaining the context. >=20 > > > + fhandler_base *fh =3D ::cygheap->fdtab[2]; > > > + if (fh && fh->get_major () =3D=3D DEV_PTYS_MAJOR) > >=20 > > For a quick test if the process is connected to a pty, you can > > use `if (istty_slave_dev (myself->ctty))' >=20 > Thanks for advice. My code is checking if the stderr is pty or > not, and write the message to output_handle_cyg if the stderr > is pty. If the stderr is redirected to another device, writing > is not done. Does istty_slave_dev() checking work same for > stderr if it is redirected? How can I get output_handle_cyg > after checking using istty_slave_dev()? Well... I didn't really think about it. YOu would have to fetch ::cygheap->fdtab[2] anyway so checking myself->ctty doesn't really help. Thanks, Corinna --=20 Corinna Vinschen Cygwin Maintainer --9/eUdp+dLtKXvemk Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAly1nWAACgkQ9TYGna5E T6D/KBAAjODeouO19fXC6mB3USQIkniIrD1hQAeNOY8SqCTAGzVzSByHhALWTDcp toKqGbZtCpgMjRiV+g3oqU5Mhc5SSF+Iisanwe7/BYNk1xa1+s+yDzfDATUe+sMj bukIEkjLbmvjWynH6jEXy6GSelKcVfeb0gSM6s+4SzdVAHStjIvUtn+14gskRrwJ gSJD1idrUhLrlX9ltK5m3DSQnyU0XeM4WHAjexA53BQUwYpPv9y7E+2SENKjrpMv ASj3mNvH7ztqy5hAlnEpKzB2NdLEH/CIlar0ImDZvFWCGm11p+QncMzHtcUOpp1U p2DBeiYgPFZnLznUJKSv+tE1NGSaKUeXmCNSQSuuM2741LgzDH22Fy9bbVycHdu7 eZdsJ6ZHy9nEu8qK0zlU7FOPyKF02Z3Eas4GTcBZJx+o9AJhxBnLJDrPTewlasD+ 0NPije7mT4mkbA3PdDOojVtii26ie5gYf1APYhy9mR5x0TtLnnV2m6WhlApkvqH9 Gnp4g73A7ChBCVFfpBy5BRSxfM5WQXZ7VoU8Ec8ob+wxUH1aL4JpuiRq59iSWbiJ 8ndKTVLSOay4ENbdCtGHS6bmpNrvCvVTqAWznNp+x2zCU4zXfNht4aST9y3aGj89 L4cFem0CfwBRrheAu8zGaxnlgqbRtvTDH+rSSY8G10gEGSCxAj4= =L9po -----END PGP SIGNATURE----- --9/eUdp+dLtKXvemk--