From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40886 invoked by alias); 14 Feb 2017 20:29:22 -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 40873 invoked by uid 89); 14 Feb 2017 20:29:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=feeds, Hx-spam-relays-external:sk:mrelaye, H*RU:sk:mrelaye, H*i:sk:6488d88 X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (217.72.192.74) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Feb 2017 20:29:20 +0000 Received: from [192.168.178.45] ([95.91.244.74]) by mrelayeu.kundenserver.de (mreue103 [212.227.15.183]) with ESMTPSA (Nemesis) id 0MQcnt-1cpSFs3W4D-00U1ex for ; Tue, 14 Feb 2017 21:29:17 +0100 Subject: Re: [ANNOUNCEMENT] Updated: dash-0.5.8-3 To: cygwin@cygwin.com References: <58893f48.0850ca0a.6c5d.5fde@mx.google.com> <81b5af354b7a3925ff0a68dcc063265f@smtp-cloud6.xs4all.net> <20170131100402.GB29504@calimero.vinschen.de> <20170131131616.GC29504@calimero.vinschen.de> <40c92f1e987a9162742766816abb4a03@smtp-cloud2.xs4all.net> <20170131153245.GA8905@calimero.vinschen.de> <09c7b42a-7b8d-52b7-ce18-4e681eb51f05@towo.net> <20170214084537.GD25846@calimero.vinschen.de> <09253e2d-af27-ddca-2b49-b65460440f69@towo.net> <6488d88d-f6b8-674d-692c-8372977a4707@redhat.com> From: Thomas Wolff Message-ID: <0da58793-0b76-1f13-aca3-06ed6aa83dc3@towo.net> Date: Tue, 14 Feb 2017 20:29:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6488d88d-f6b8-674d-692c-8372977a4707@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-UI-Out-Filterresults: notjunk:1;V01:K0:vl20oVCtVwM=:wLkqweRBomRcCbYr9XetAJ cNUWGVaVG/cq+WTEeEnDu3sbOxMhIu3AofmF0jsFN+QB6qoS6MpZ+2+l3ww2s2GSB6oFS+8PN Rq7uCq3NuotE7oh50prxCsLkOApyKhRkqdhQqQMDWvuJ7LIgNn/FKC/O9bFkxs5Z/J2iBP7QX DJc+9/9pDOl+APu6NQjLLADikfdAV7GPMyGUbDUIulzc+STAZPIA9mcZ32IYixa2WVKhmzZv2 SDC/G+o/+Wv0+xptcz6MjFeGnDnBgThuH0kTsS/vqBlDGQrpy7FTQZINY676PJF66JZ4TB9yh LNerp8CoUSx0Y11OwPX+f1IRpZLlcfj/TAba9KuomL5euriAhnoitdNfRcARBm6+/9DlzSAzX nInbwTKGShTef9JkyfCiieA2HUwO1/Y8gfpVq+SkOro2DHrBn62I1W5TFNGF4aujpfp9G6/cs Gdp4Hzn5JEUrTQHBIMEZ4to+evT1e/ePtzqWW88HD/o213B76s73rp4JZzuY+XdeUGZ8WxpvR yKz0Gxid4HhcvVbYG1hnMuz9ct4AkNOm9Jze6y0+eBuX6vzQ35f59CLyA2sOgCJwgBCvnzqYu I1TBxeu36JMw7MOOW+IxuukkCXOZ0HtXz6+fRTBtH38VgulwUVKHovdZgYrqe7tADjeNGvHPP IFJBMRW3I1vzYxxPqK8wPnzClIwUZnb0C7WB+tm5CY9h5l+KqOe+DK65Ye2k7mwFMnZdK+Apm KHUtsCbc0tRCk/pI X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00193.txt.bz2 Am 14.02.2017 um 20:56 schrieb Eric Blake: > On 02/14/2017 01:40 PM, Thomas Wolff wrote: >>> No. We're talking about a function in the master side of the tty, while >>> the applications started in the terminal are on the slave side. >> I am not familiar with the concept of setting termios properties on >> either the master or slave side of a pty. I've only ever set them in the >> client application, including my tests about IUTF8 which worked. Would >> setting on the master side imply it's set for the clients implicitly, >> and can it be changed later, e.g. when mintty character encoding is >> being changed from the Options dialog? >> And you say the function of erasing characters on BS is in the master >> side? To be honest, this confuses me. I thought it's a client function, >> like readline() would perform if used (apparently not by dash), which is >> kind of an enhanced version of the tty cooked mode and used to work even >> without the new flag, right? > The readline source code does not mention IUTF8; and neither bash nor > dash need to reference it, because if the tty handling code sets it > correctly for what the terminal is going to display, then the clients > that are read()ing from the tty never even see BS in cooked mode (the > master side of the terminal handles BS before the read() completes in > the slave, if I'm understanding it correctly). This does not comply with my (limited) understanding of pty stuff. In mintty, forkpty will create a master/slave pty; mintty feeds it on the master side, while the client program (usually a shell) reads from the slave side. Mintty never handles BS for input, it simply feeds it into the pty. "Line disciplines" like cooked mode must be handled on the slave side. >>> iutf8 is set in Linux by default and by most terminal applications ionly >>> reset if the LC_CTYPE setting in the environment of the terminal >>> application is not set to the utf8 codeset. This is determined at >>> terminal startup, not by the inferior processes runnin in the terminal. >>> The applications still can set iutf8 via termios control (or stty(1)). >> Will you patch stty as well to address the new flag? > Already patched; coreutils-8.26-2 was promoted to current yesterday. > >>> For mintty I just thought it might be helpful to honor the character set >>> setting in its options and to default to iutf8 if it's not set. >> Sure, but it would be better to find a solution that implicitly works in >> all terminals. Isn't it possible to handle this in forkpty()/openpty()? > Does forkpty()/openpty() currently pay attention to environment > variables to even know what encoding is currently in use? Don't know, but maybe it simply should for this purpose, for a widely-useful solution. > And what's to > say that the environment used to fork the master side will match the > locale settings of the slave process that connects to the pty, so how do > we know whether to default IUTF8 on or off based solely on the slave's > environment, when it is the master that is handling BS and therefore the > master's character encoding that matters for how much BS should erase ? See above; the master isn't handling BS. But there should be no such inconsistency in the case of mintty because master and slave are forked from common initial code. I think this consideration is only relevant for reattaching programs like screen. ------ Thomas -- 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