Mail Archives: cygwin/2015/03/24/15:54:00
--ZGiS0Q5IWpPtfppv
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mar 24 19:59, Denis Excoffier wrote:
> On 2015-02-28 16:30, Corinna Vinschen wrote:
> > I can not reproduce this in mintty, nor in a Cygwin xterm started on a
> > remote X server running under Linux. I can reproduce this with a local
> > xterm started via startxwin. But, and that's the problem, I can
> > reproduce it with the current 1.7.35-0.5 test release, with 1.7.34, and
> > last but not least also with a debug version of the Cygwin DLL in which=
I
> > backed out all PTY-related changes since last November.
> >=20
> > I'm not sure this is a giveaway, but from that it seems this problem
> > is not directly related to a Cygwin change in the last months.
> >=20
> > So, jturney and I are wondering when exactly you encountered this probl=
em
> > for the first time. Did it coincide with a certain Cygwin release,
> > or a certain X server? Or new X libs, perhaps?
> >=20
> > Anything you can provide to narrow down the potential culprit would be
> > helpful.
> >=20
> Well. Here is some more inputs.
>=20
> This is connected with the "min" option of stty. When this occurs,
> 'stty -a' says '4' for min. If i change into 'stty min 5' the characters
> come by chunks of 5.
>=20
> I had a look into the sources of xterm, xinit, coreutils, tcsh and cygwin=
and
> i definitely don't understand where the 4 comes from. In any case, 4 shou=
ld not be
> the problem, because 'stty min 4' is perfectly legitimate.
>=20
> The doc of stty says that 'min' (and 'time') are used in case of '-icanon=
'.
> However, i found in fhandler_tty.cc that it seems not to be always the ca=
se.
> After i applied the following patch:
>=20
> diff -uNr cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.=
cc cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc
> --- cygwin-snapshot-20150317-1.original/winsup/cygwin/fhandler_tty.cc 201=
5-03-17 11:42:16.000000000 +0100
> +++ cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc 2015=
-03-24 19:32:42.000000000 +0100
> @@ -715,7 +715,7 @@
>=20=20
> if (is_nonblocking () || !ptr) /* Indicating tcflush(). */
> time_to_wait =3D 0;
> - else if ((get_ttyp ()->ti.c_lflag & ICANON))
> + else if (!(get_ttyp ()->ti.c_lflag & ICANON))
No, this is wrong. You're switching the code for icanon with the
code for -icanon. -icanon in stty means ICANON is switched off.
I just gave it another try and the behaviour is perfectly valid.
The real problem is that "something" is setting VMIN to 4. And that's
somehow inside the X server, if I'm not completely wrong:
- If you start an xterm from mintty like this:
xterm -display :0
and then call `stty -a' in it, you'll see that min is 1, and then
script will behave as desired.
- However, if you start xterm from the X server tray icon and then
call `stty -a' in it, min is set to 4 and script will misbehave.
If you call `stty min 1' before calling script, script will work
as expected again.
So, why does the X server (or whatever controls starting applications
from the X server tray icon) set VMIN to 4?
Corinna
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--ZGiS0Q5IWpPtfppv
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJVEcDDAAoJEPU2Bp2uRE+gqrkP/1FTSFYpKPMpAoKo8Oj8cgFf
10yw+9ZaCJ2RmXgmWs/LAj6LJWZRTDgR07mb1QSi0XpJ2CFpnJVTkDU1g3HJyqo0
41BQc/t9KGitYsiIJ2gKere/uV1OSkJMfcOGEQbOkZYm+iFucjmBKD8V0Uu7SdgW
aXeqFWguzA2sGyVdT0yOh1PMOP14AT8zwWIbQvtlu0mKVm1AMFyva+hxKPWwM6oo
yiDBLtRFHYRphxLtjDyR8T7lcLAwCuh+YCHVRCLSRrscvytF30uQsIRoKjg+GcJf
3Arfs3JUDP22TYnKkO5QjvryrDqOX2q+MSe/rYsRITLh7Egxq60ao5AU1IlWBBmR
UAqRud5J7fVXSJ8U70zyHRd0X3Cqc9CkYIXodzRwEui3TrEw/GBA29Pj7MMwfj9j
QECU6J5Y0FUqp1HR7i7UknilaQFMq/3SF/RCPpeytOvznrVnBpao85e+7sIfS4co
4NG+8yWmGqKrtwM3nAVzsY6qMec8C7ozF1VkKJlJ2xSWobJHulAZjGb0x+ARve6w
nV4mPpxqUMEj3D/A/Arh2wSilg7EqLJJeeQnvvzR53/lgAhUu4CKEzOdan4GxR2F
SqmjTc+IemXFzZSLHtBlKxMqE/dSpjHr5YUzK98k1WUERNKXBKF+Uz6/+eSRvbMc
dhYZ7nUPJfQHZyG4l+6Y
=0zXt
-----END PGP SIGNATURE-----
--ZGiS0Q5IWpPtfppv--
- Raw text -