This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Updated: dash-0.5.8-3

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


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]