[ANNOUNCEMENT] Updated: dash-0.5.8-3

[Thomas Wolff]

Am 16.02.2017 um 13:49 schrieb Corinna Vinschen:
> On Feb 15 23:19, Thomas Wolff wrote:
>> Am 14.02.2017 um 21:35 schrieb Thomas Wolff:
>>> Am 14.02.2017 um 21:29 schrieb Thomas Wolff:
>>>> 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.
>>> Also, I've tried both options in mintty. Setting the flag on the master
>>> side has weird effects, initially blocking the terminal process.
>>> Setting it on the slave side works fine.
>> That was a mistake (got something wrong when testing). It works from either
>> side alike.
>> I've now patched mintty to keep the flag in sync with the character
>> encoding, including on later changes (from Options menu or by escape
>> sequence).
> There's an ESC sequence to change the codeset?  Do you mean the
> alternate codeset sequence \e[10m / \e[11m
Oh, that one! Thanks for mentioning, I had overlooked it and fixed 
mintty now to consider it.
> or is there something more sophisticated?
I actually meant to adress 
https://github.com/mintty/mintty/wiki/CtrlSeqs#locale and there is also 
\e%G and \e%@.

I just notice that later changing of the IUTF8 flag from the master side 
does not seem to work on a Window 10 system (although it works 
initially) while it does work on a Windows 7 system. Weird.

------
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