Christopher Faylor <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]:
>>> Daniel Miller <[EMAIL PROTECTED]> wrote in >>> news:[EMAIL PROTECTED]: >>> >>> I propose that this is *not* really off-topic, since the problems that >>> I'm experiencing do not occur in cmd.exe, nor in 4NT, only in Bash. >>> So it's something Bash is doing in its environment that is breaking >>> StdOut, at least relative to whatever Win32 looks at. >>> > > Why does it matter? If that was the case, are you asking if we will > change cygwin to help get your application working? If so, the answer > is "no". > > You've found your problem. Don't use STD_OUTPUT_HANDLE for this purpose. > Use STD_INPUT_HANDLE instead. Problem solved. > Actually, no, problem not solved. First of all, disregarding the redirection issue entirely, GetConsoleScreenBufferInfo() is used in Win32 programs to get information about the console configuration. I need that information regardless. STD_INPUT_HANDLE does *not* solve the problem, it isn't valid at all in that function, even in a normal console (cmd.exe) (I tested it). The StdOut handle is used because I want info about the window I'm writing to. The function works properly in every console except Bash, which is why I'm presenting the issue on this group. I don't think this is an unreasonable request. Besides, I'm not necessarily suggesting that the problem is even with Bash itself, since Bash works on another XP machine. I'm mainly trying to figure out what the difference is between XPPro+Bash and XPHome+Bash. But either way, Bash itself *is* a required component in creating this failure mechanism; no other console program produces it... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
