From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99557 invoked by alias); 24 Jun 2019 10:53:43 -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 99000 invoked by uid 89); 24 Jun 2019 10:53:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-101.6 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,RCVD_IN_DNSWL_NONE,UNSUBSCRIBE_BODY autolearn=ham version=3.3.1 spammy=apps, connected, HTo:U*cygwin-developers, H*Ad:U*cygwin-developers X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.17.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Jun 2019 10:53:41 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.183]) with ESMTPSA (Nemesis) id 1M7JrG-1heHCo2Oia-007iii for ; Mon, 24 Jun 2019 12:53:38 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 04466A8076D; Mon, 24 Jun 2019 12:53:38 +0200 (CEST) Date: Mon, 24 Jun 2019 10:53:00 -0000 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: [PATCH v5 1/1] Cygwin: pty: add pseudo console support. Message-ID: <20190624105337.GC5738@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> <20190416091616.GN3599@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: <20190416091616.GN3599@calimero.vinschen.de> User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-06/txt/msg00000.txt.bz2 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3088 Hi Takashi, On Apr 16 11:16, Corinna Vinschen wrote: > 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. >=20 > Huh, crazy. Thanks for explaining the context. >=20 > >=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()? >=20 > 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. Any news on this? Do you consider the latest state from April stable enough for master? Thanks, Corinna --=20 Corinna Vinschen Cygwin Maintainer --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAl0Qq7EACgkQ9TYGna5E T6CJdg//dgMNViZSEuxDzgYy08MHAEt6YomDDe7Z+CwUkABf5El2bp6KpK16G9j+ tTg7R9w7PcYn4qJeiCsx8VFybWc2G2uSl1gVEfzSXMVY/4gOoFI3mmq/IUGsfG5Q fshWEy88qzQmaV0sB0ZV4FnejEUx3NhSMZjwPcN6Ajt7gWh/6io6mYIs/TVBXtZS 1rzE+AAytWeShq5Gq0/iRKWjiytXmd6YZcRqHOWGBFbGh93zlnUZ0EN27b4IwuHY ZgSX2Eb4HPT0X2r3usKEqKkDOzxQOPpbNSFvMUPWKp6VWAjOMfa4ui0OPN//HHia gsHKu0UgyZRisTdDKV8ijj9ecEqIwCjVORGj4Jr4TwZiFc7My1Q88DTCjBDhzaZH KBHkvHsHxmIoSdzxljOJT8U7mzHU3Der/svZ2lW8GTWFJDoOIWTyHW0BceGyAfAR ulBBoT3KSO3OhcaZl6pxNvl6vyHjmihWDqy62ccBV0UVrz3rys+WqupIgqZVjC3W op3thFco9xAPz/lYZ+xiwypMIYAkU/uybhxd4LgZbK7Ql04ssxDz3LbNuciuLl1G Cr4/l7ikrUnETkJF4iY7McPlCockpHaoG8Uf0h43H4ZDEyfkw6y5wVWPxwEeuueX WJIq3zFtLvG8eYL+Ra9m54Rs991RmXKJt30NpD3D+yUgljE2POo= =SLi0 -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd--