Mail Archives: cygwin/2004/10/13/18:19:22
Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com> wrote in
news:20041013205759 DOT GI8866 AT trixie DOT casa DOT cgf DOT cx:
>>> Daniel Miller <dan AT imi-test DOT com> wrote in
>>> news:Xns958070E64AD1Adancarddupercom AT 80 DOT 91 DOT 229 DOT 5:
>>>
>>> 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/
- Raw text -