This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Bash: when is WinXP not WinXP??

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

  Hey Dan! !

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

The GetConsoleScreenBufferInfo function retrieves information about the
specified console screen buffer. 
[in] Handle to a console screen buffer. The handle must have GENERIC_READ
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. 

  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

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

Can't think of a witty .sigline today....

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]