X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_20,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <001001cb23a5$3a879090$af96b1b0$@gmail.com> References: <000801cb2383$9c3ad3a0$d4b07ae0$@gmail.com> <20100714184922 DOT GA13548 AT ednor DOT casa DOT cgf DOT cx> <001001cb23a5$3a879090$af96b1b0$@gmail.com> Date: Sun, 12 Sep 2010 22:29:56 +0100 Message-ID: Subject: Re: {lp,cb}Reserved2 under Windows 7 and file descriptors From: Andy Koppe To: cygwin AT cygwin DOT com Content-Type: multipart/mixed; boundary=002215974c5a6e1784049016ae06 X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com --002215974c5a6e1784049016ae06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 14 July 2010 23:38, Daniel Colascione wrote: > there is a very long-standing issue with Cygwin pty devices: > while Cygwin programs report true from isatty() when called on a Cygwin P= TY, > MSVCRT applications do *not*. From their point of view, Cygwin ptys are n= ot > ttys, which has led to all sorts of trouble over the years. Because Windo= ws > lacks a pseudoconsole facility, it's not possible to solve the problem in > general (though some people, like the author of conin, have taken some st= eps > in that direction). > > However, due to the way the CRT works, we can fool it into thinking a > passed-in file descriptor is actually a tty. All you need to do is use 3 = for > the value of *lpReserved2, then follow it with three flag bytes, then thr= ee > HANDLE values --- corresponding respectively to flags[fd0], flags[fd1], > flags[fd2] and fh[0], fh[fd1] and fh[fd2]. =C2=A0This information would be > followed by the normal child_info structure. If stdin, stdout, or stderr = is > a Cygwin PTY, Cygwin can manually set the FDEV bit (described in the old > MSDOS headers) in corresponding flag byte, which will make _isatty() retu= rn > true in the child. > > (Not that I've actually tried it --- it's just an idea.) This does appear to work! Proof-of-concept code attached, along with a couple of tests. Running in mintty: $ gcc-3 -mno-cygwin fdev.c -o fdev $ gcc-3 -mno-cygwin isatty.c -o isatty $ gcc-3 -mno-cygwin input.c -o input First test: just calling isatty(). $ ./isatty isatty(0)=3D0 isatty(1)=3D0 isatty(2)=3D0 $ ./fdev ./isatty isatty(0)=3D64 isatty(1)=3D64 isatty(2)=3D64 Second test: prompting with printf, reading with scanf. This comes from mintty issue 218. Problem here is that stdout is fully-buffered if it's a pipe, with the consequence that the prompt doesn't appear until after input. $ ./input 12 Please input a number The number is 12 Fine through fdev though: $ ./fdev ./input Please input a number 12 The number is 12 Unfortunately it only seems to work for fdev's direct child process though. For example, when running cmd.exe through fdev and invoking isatty.exe from there, it's all zeroes from isatty() again. I suspect the common case is to run Windows programs directly from bash though, so this might still be worth having in spawn()/exec(). Alternatively, it could be provided as a wrapper that has to be invoked explicitly. Andy --002215974c5a6e1784049016ae06 Content-Type: application/octet-stream; name="fdev.c" Content-Disposition: attachment; filename="fdev.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ge0dz7pn0 I2luY2x1ZGUgPHdpbmRvd3MuaD4KCiNkZWZpbmUgRk9QRU4gMHgwMQojZGVm aW5lIEZERVYgIDB4NDAKCmludAptYWluKGludCBhcmdjLCBjaGFyICphcmd2 W10pCnsKICBpbnQgY2JSZXNlcnZlZDIgPSA0ICsgMyAqIDU7CiAgY2hhciAq bHBSZXNlcnZlZDIgPSBtYWxsb2MoY2JSZXNlcnZlZDIpOwogIAogICooaW50 ICopbHBSZXNlcnZlZDIgPSAzOwogIAogIGNoYXIgKmZpbGVfZmxhZ3MgPSBs cFJlc2VydmVkMiArIDQ7CiAgZmlsZV9mbGFnc1swXSA9IEZPUEVOIHwgRkRF VjsKICBmaWxlX2ZsYWdzWzFdID0gRk9QRU4gfCBGREVWOwogIGZpbGVfZmxh Z3NbMl0gPSBGT1BFTiB8IEZERVY7CgogIEhBTkRMRSAqZmlsZV9oYW5kbGVz ID0gKEhBTkRMRSAqKShscFJlc2VydmVkMiArIDQgKyAzKTsKICBmaWxlX2hh bmRsZXNbMF0gPSBHZXRTdGRIYW5kbGUoU1REX0lOUFVUX0hBTkRMRSk7CiAg ZmlsZV9oYW5kbGVzWzFdID0gR2V0U3RkSGFuZGxlKFNURF9PVVRQVVRfSEFO RExFKTsKICBmaWxlX2hhbmRsZXNbMl0gPSBHZXRTdGRIYW5kbGUoU1REX0VS Uk9SX0hBTkRMRSk7CiAgCiAgU1RBUlRVUElORk8gc3VpID0gewogICAgLmNi ID0gc2l6ZW9mIHN1aSwKICAgIC5jYlJlc2VydmVkMiA9IGNiUmVzZXJ2ZWQy LAogICAgLmxwUmVzZXJ2ZWQyID0gbHBSZXNlcnZlZDIKICB9OwogIFBST0NF U1NfSU5GT1JNQVRJT04gcGk7CiAgQ3JlYXRlUHJvY2VzcygwLCBhcmd2WzFd LCAwLCAwLCBUUlVFLCAwLCAwLCAwLCAmc3VpLCAmcGkpOwogIFdhaXRGb3JT aW5nbGVPYmplY3QocGkuaFByb2Nlc3MsIElORklOSVRFKTsKICByZXR1cm4g MDsKfQo= --002215974c5a6e1784049016ae06 Content-Type: application/octet-stream; name="isatty.c" Content-Disposition: attachment; filename="isatty.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ge0e05m91 I2luY2x1ZGUgPHN0ZGlvLmg+CgppbnQgbWFpbih2b2lkKQp7CiAgcHJpbnRm KCJpc2F0dHkoMCk9JWlcbiIsIGlzYXR0eSgwKSk7CiAgcHJpbnRmKCJpc2F0 dHkoMSk9JWlcbiIsIGlzYXR0eSgxKSk7CiAgcHJpbnRmKCJpc2F0dHkoMik9 JWlcbiIsIGlzYXR0eSgyKSk7Cn0K --002215974c5a6e1784049016ae06 Content-Type: application/octet-stream; name="input.c" Content-Disposition: attachment; filename="input.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ge0e0b4f2 I2luY2x1ZGUgPHN0ZGlvLmg+CgppbnQgbWFpbihpbnQgYXJnYywgY2hhciog YXJndltdKXsKICAgIGludCBuOwogICAgcHJpbnRmKCJQbGVhc2UgaW5wdXQg YSBudW1iZXJcbiIpOwogICAgc2NhbmYoIiVkIiwgJm4pOwogICAgcHJpbnRm KCJUaGUgbnVtYmVyIGlzICVkXG4iLCBuKTsKICAgIHJldHVybiAwOwp9Cg== --002215974c5a6e1784049016ae06 Content-Type: text/plain; charset=us-ascii -- 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 --002215974c5a6e1784049016ae06--