Who's using "CYGWIN=tty" and why?

[Edward Lam]

On 5/11/2011 2:34 AM, Corinna Vinschen wrote:
> Kind of weird.  The difference is that in tty mode the stdio handles are
> pipes, while in the notty case the stdio handles are console handles.
> Usually native Windows applications shouldn't see a difference and even
> work *better* in notty mode.

One problem I ran into was with *Windows mode* applications (ie. MS 
link.exe option /SUBSYSTEM:windows) trying to detect stdout redirection. 
I apologize that this takes a bit of explaining first as to why we run 
into a problem with Cygwin.

For Windows-mode applications, _isatty(_fileno(stdout)) will always 
return false. Due to a bug (in Windows and/or the CRT), the FILE *stdout 
object will be initialized to a black hole. So if you want printf's to 
make its way into the redirected file, you have to manually connect the 
FILE *stdout object to the redirected file output handle.

The usual method is to call GetStartupInfo(&info) and check if 
info.dwFlags has the STARTF_USESTDHANDLES flag set. If it is set, then 
assume that info.hStdOutput contains the redirected file output handle 
and attach it with something like:
    *stdout = _fdopen(_open_osfhandle(info.hStdOutput, _O_TEXT));

So this brings us to Cygwin. When we spawn such a Windows mode app from 
Cygwin, the method I describe above fails. The call to 
_open_osfhandle(info.hStdOutput, _O_TEXT) returns with an error value of 
-1. This is likely why jam reports "the handle is invalid".

Personally, when I first ran into this problem, I never realized that 
CYGWIN=tty would fix it. I did notice that there was a change in the 
behavior between Cygwin B20 and the Cygwin 1.X releases but I only 
realize now that this was probably the reason.

Regards,
-Edward

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