RE: Bash: when is WinXP not WinXP??

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Daniel Miller
> Sent: 13 October 2004 01:57

[Reply-To set on "TITTTL"!]

> "Dave Korn" <dk [GADZOOKS!] artimi [WHOOPSVICAR] com> wrote in
> NUTMEGd8PXibjXt5tX800000407@NUTMEG.CAM.ARTIMI.COM:">news:NUTMEGd8PXibjXt5tX800000407@NUTMEG.CAM.ARTIMI.COM: 

  Hey Dan!  http://cygwin.com/acronyms#PCYMTNQREAIYR !

> >> -----Original Message-----
> >> From: cygwin-owner On Behalf Of Daniel Miller
> >> Sent: 12 October 2004 19:06
> > 
> >> under Bash.  Under WXPPro/Bash it worked fine.  However, 
> under Home 
> >> edition, my utility apparently thinks its output is being 
> >> redirected, so it tries to generate the output as html code 
> >> (to preserve colors), which of course generates tons of garbage.
> > 
> >   Then your code has a bug.  Whatever technique it is using 
> to decide if it is being redirected is wrong.  

> Well, the code that's causing me to think I'm redirected is:
> 
>    hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);
>    PERR(hStdOut != INVALID_HANDLE_VALUE, "GetStdHandle");
>    bSuccess = GetConsoleScreenBufferInfo(hStdOut, &sinfo) ;
>    if (bSuccess == false) {
>     	 //  this returned "The handle is invalid"
>       fprintf(stderr, "gcsbi error: %s\n", get_system_message()) ;
>       exit(1) ;
>       redirected = 1 ;
>       return ; 
>    }

  Hmm.  That's the first time I've heard of GetConsoleScreenBufferInfo.
Let's see what MSDN says about it:

------------------------------<fairuse>------------------------------
The GetConsoleScreenBufferInfo function retrieves information about the
specified console screen buffer. 
------------------------------<fairuse>------------------------------
Parameters
hConsoleOutput 
[in] Handle to a console screen buffer. The handle must have GENERIC_READ
access. 
lpConsoleScreenBufferInfo 
------------------------------<fairuse>------------------------------
Return Values
If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error
information, call GetLastError. 
------------------------------<fairuse>------------------------------

  Right.  So I would suggest that all you can reasonably infer from bSuccess
being false is that the function failed.  You are going one step beyond that
in deducing that if the function fails, the handle must not be a console
screen buffer handle.  There are of course other reasons why the function
might fail.  You should have called GetLastError, then you'd have more
information about what was going on.

> So even if I did as you suggest above, I would still have to 
> terminate my 
> program when GetConsoleScreenBufferInfo failed... 

  Or operate with different/reduced functionality.  Many *nix tools operate
differently, e.g. non-interactively, when used in pipes, e.g. 'man' or
'info'.

> Now *why* is that 
> function failing on hStdOut, which was not itself invalid (since 
> GetStdHandle succeeded)... ??  And again, why only on the 
> Home machine, 
> not on the Pro machine??

  Good question.  Is one of them SP2 but not the other?  I reckon it'll be
some kind of device perms/acls problem; let's see if GetLastError returns
ACCESS_DENIED or something else like INVALID_HANDLE.

  BTW, since this is really now about win32 coding and getting OT, I'm
redirecting it to the talk list.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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