X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=l8JiFRijiF28QhuP
	RYnyEcwb7FyYWjPTH0DUxTAZIrBx6H8hVmNzXP5f9WF4ZWu8tFujwfc4a97oAVqA
	X+oyS4GudllULMOwQ5H23k3RUDBHyXY2KFgWD47UyaNPCnnYrO/fakd5VTXCr2Hz
	jnjs+RzhptFntYfsb1nh8sB2TDo=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=bGOClbDH9obqsrjIffi3I+
	EHWVE=; b=QCM0AIRhAL4xrld43ZnQ178ctAqoaON/k7zJUYEZKLh8AtD15raESS
	opD1cXYXkO6DGzCvSoegA8PFauK4dt3r+r/93ojU/CIUpveRb09MOW7PgMzr+7oW
	lqygLFLDHfObz/o6bKmCph6f/vyhNIb9bqW1HfW+GbnpKVOUj33yE=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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
Subject:	Re: [ANNOUNCEMENT] Updated: dash-0.5.8-3
To:	cygwin AT cygwin DOT com
References:	<d58b09904f6fc607e5c044e67a02f393 AT smtp-cloud3 DOT xs4all DOT net> <58893f48 DOT 0850ca0a DOT 6c5d DOT 5fde AT mx DOT google DOT com> <81b5af354b7a3925ff0a68dcc063265f AT smtp-cloud6 DOT xs4all DOT net> <20170131100402 DOT GB29504 AT calimero DOT vinschen DOT de> <20170131131616 DOT GC29504 AT calimero DOT vinschen DOT de> <40c92f1e987a9162742766816abb4a03 AT smtp-cloud2 DOT xs4all DOT net> <20170131153245 DOT GA8905 AT calimero DOT vinschen DOT de> <09c7b42a-7b8d-52b7-ce18-4e681eb51f05 AT towo DOT net> <20170214084537 DOT GD25846 AT calimero DOT vinschen DOT de> <09253e2d-af27-ddca-2b49-b65460440f69 AT towo DOT net> <6488d88d-f6b8-674d-692c-8372977a4707 AT redhat DOT com>
From:	Thomas Wolff <towo AT towo DOT net>
Message-ID:	<0da58793-0b76-1f13-aca3-06ed6aa83dc3@towo.net>
Date:	Tue, 14 Feb 2017 21:29:17 +0100
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>
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

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

- Raw text -