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
