From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59199 invoked by alias); 25 Mar 2015 15:26:06 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 59190 invoked by uid 89); 25 Mar 2015 15:26:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: smtp5-g21.free.fr Received: from smtp5-g21.free.fr (HELO smtp5-g21.free.fr) (212.27.42.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 25 Mar 2015 15:26:04 +0000 Received: from [192.168.0.11] (unknown [78.224.52.79]) by smtp5-g21.free.fr (Postfix) with ESMTP id 585FED4806C; Wed, 25 Mar 2015 16:24:28 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: X server sets VMIN? (was Re: Under /bin/script, characters get printed in four-character chunks) From: Denis Excoffier In-Reply-To: <20150324195339.GA32703@calimero.vinschen.de> Date: Wed, 25 Mar 2015 16:05:00 -0000 Content-Transfer-Encoding: quoted-printable Message-Id: <641C04A3-5059-48A5-830D-4B095935366B@Denis-Excoffier.org> References: <0B1779D1-F99A-4B3A-87FB-50AE581FD1B7@Denis-Excoffier.org> <20150228121357.GS11124@calimero.vinschen.de> <20150228153035.GD11124@calimero.vinschen.de> <20150324195339.GA32703@calimero.vinschen.de> To: cygwin@cygwin.com X-SW-Source: 2015-03/txt/msg00454.txt.bz2 On 2015-03-24 20:53, Corinna Vinschen wrote: >=20 > 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 cygwi= n and >> i definitely don't understand where the 4 comes from. In any case, 4 sho= uld 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 '-icano= n'. >> However, i found in fhandler_tty.cc that it seems not to be always the c= ase. >> 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 20= 15-03-17 11:42:16.000000000 +0100 >> +++ cygwin-snapshot-20150317-1.patched/winsup/cygwin/fhandler_tty.cc 201= 5-03-24 19:32:42.000000000 +0100 >> @@ -715,7 +715,7 @@ >>=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)) >=20 > No, this is wrong. You're switching the code for icanon with the > code for -icanon. -icanon in stty means ICANON is switched off. >=20 > I just gave it another try and the behaviour is perfectly valid. >=20 > 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: >=20 > - If you start an xterm from mintty like this: >=20 > xterm -display :0 >=20 > and then call `stty -a' in it, you'll see that min is 1, and then > script will behave as desired. >=20 > - 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. >=20 > So, why does the X server (or whatever controls starting applications > from the X server tray icon) set VMIN to 4? >=20 It seems that this has something to do with tcsh (and not with XWin). If you arrange your environment in order that the xterm launches /bin/bash (instead of tcsh), you get min=3D0 under 'stty -a' and /bin/script behaves as expected. If afterwards, in such an xterm, you run '/bin/csh -f', you get min=3D4. Consider the following: diff -uNr tcsh-6.18.01-original/ed.init.c tcsh-6.18.01-patched/ed.init.c --- tcsh-6.18.01-original/ed.init.c 2006-08-24 22:56:08.000000000 +0200 +++ tcsh-6.18.01-patched/ed.init.c 2015-03-25 15:56:33.000000000 +0100 @@ -65,7 +65,7 @@ (uc)CDSWTCH, (uc)CERASE2, (uc)CSTART, (uc)CSTOP, (uc)CWERASE, (uc)CSUSP, (uc)CDSUSP, (uc)CREPRINT, (uc)CDISCARD, (uc)CLNEXT, (uc)CSTATUS, (uc)CPAGE, - (uc)CPGOFF, (uc)CKILL2, (uc)CBRK, (uc)CMIN, + (uc)CPGOFF, (uc)CKILL2, (uc)CBRK, (uc)1, (uc)CTIME }, { In the original code, CMIN is set to CEOF and CEOF is set to Control-D, hen= ce min=3D4. With the patch above, all seems to go well. But this does not explain why the min=3D4 is not permanent. Regards, Denis Excoffier. -- 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