From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22752 invoked by alias); 8 Aug 2019 19:24:39 -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 22638 invoked by uid 89); 8 Aug 2019 19:24:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-102.1 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,RCVD_IN_DNSWL_NONE,UNSUBSCRIBE_BODY autolearn=ham version=3.3.1 spammy=april, April, screen, device X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (217.72.192.75) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Aug 2019 19:24:37 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1McY0J-1iS7ZD3f8H-00d10n; Thu, 08 Aug 2019 21:24:31 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 3FB2DA80704; Thu, 8 Aug 2019 21:24:29 +0200 (CEST) Date: Thu, 08 Aug 2019 19:24:00 -0000 From: Corinna Vinschen To: Takashi Yano Cc: cygwin-developers@cygwin.com Subject: Re: [PATCH v5 1/1] Cygwin: pty: add pseudo console support. Message-ID: <20190808192429.GS11632@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: Takashi Yano , 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> <20190624105337.GC5738@calimero.vinschen.de> <20190725143149.GD11632@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OHFW44Kv8gQ39vd8" Content-Disposition: inline In-Reply-To: <20190725143149.GD11632@calimero.vinschen.de> User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-08/txt/msg00000.txt.bz2 --OHFW44Kv8gQ39vd8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3730 Hi Takashi, desperately trying again, this time directly to you. I hope you're doing well. Corinna On Jul 25 16:31, Corinna Vinschen wrote: > I hope you're still with us? >=20 >=20 > Corinna >=20 > On Jun 24 12:53, Corinna Vinschen wrote: > > 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 sin= gle > > > > > 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 connec= ted > > > > > 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. > >=20 > > Any news on this? Do you consider the latest state from April > > stable enough for master? > >=20 > >=20 > > Thanks, > > Corinna > >=20 > > --=20 > > Corinna Vinschen > > Cygwin Maintainer >=20 >=20 >=20 > --=20 > Corinna Vinschen > Cygwin Maintainer --=20 Corinna Vinschen Cygwin Maintainer --OHFW44Kv8gQ39vd8 Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAl1Mdu0ACgkQ9TYGna5E T6BmPBAAhgMMdXLUVweycxGZScX2fGN1AoP/HPtYzDOYTkxDE9pwRA+vhvNEdSAb 1mhoa4EoyS/ACbk6kHTbVbhz0B3jwaxgEwq5DuLjV5EGM3JaXkrwszIAngnpU7LW W2xo0/EwO9ml7Yljpj4PQ4GrE8DR/Ozv752R35thMnPjUkmz7MqpN+tShAmSZcAH 5oUnItYmea+MSl1PQ6acTQmXubkq6EsfImV1e6iY6fHp8D0KhtWZUyAKk7I/H9og 1LjHPSNQM9G7yCqlPXGER7RwtXUW0QMp46ZFGDebZ/O3RFzyY4jO+5UH+hj36R6J z8qfVC2KcwpmCN885sDijzzhWrXCzeo5hmB+HKtGb3iIHEi5Z+cO82S5Z4EB6i6J ypkUFchp0QpmQj4DXjVu3hgrhNjlYwsWEJf2XpwXDl9xbNiCSvw7n4NqzQJlA9TW C1JD5VNxjDa8u/j8xRUwPb3UWGK0V0VZLjTE/taC94pKre0HF4yokBGUGFWw2LO+ qVKTZEEf1DEwGG+E1loE4BOm2+8t0mnjtdPHgRPXjBwnDzhArb+RONVW4cMdORik VlSwxXTAuZfJWYePnugR3ofP5br1L81EiUvc9AfIFXyGdWcgQ1vhj3+4TNhbGwjj f32wFDS24CGuoDNhJ+GAX7Yeejfc//dq46XZr/IBLNYoQ2ko5Dc= =z1jM -----END PGP SIGNATURE----- --OHFW44Kv8gQ39vd8--