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

Problem reports:
Unsubscribe info:

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