KfW 3.1: Re-directed stderr of kinit/klist displays dialog

[petesea@bigfoot.com]

On Tue, 20 Feb 2007, Christopher D. Clausen wrote:

> Well, can't you check the exit error codes set by the program?
>
> C:\>kinit -kt test
> kinit(v5): Cannot resolve network address for KDC in requested realm
> while getting initial credentials
> C:\>echo %ERRORLEVEL%
> 1

Because that only tells you there was SOME kind of problem.  It doesn't 
tell you what the problem was.

I'm running kinit -kt as a background job ("Scheduled Task").  If it fails 
I'd like to be able to log the reason it failed so I know how to fix it. 
Just knowing that it failed doesn't really help much.

> Also, I can redirect the klist output just fine.  What are you doing?
>
> C:\>klist 2>&1 1>%TEMP%\test.txt
> C:\>cat %TEMP%\test.txt
> Ticket cache: API:notguest at AD.UIUC.EDU
> Default principal: cclausen at AD.UIUC.EDU
> Valid starting     Expires            Service principal
> 02/20/07 18:14:49  02/21/07 04:14:49  krbtgt/AD.UIUC.EDU at AD.UIUC.EDU

stdOUT can be re-directed just fine, it's only stdERR that can't.  Try 
this:

   C:\>klist -c foobar 2>klist.out

where "foobar" is a file that does NOT exist.  This will generate an error 
and since stderr is re-directed to a file, displays a Windows dialog.

Using the exact re-direct syntax you used, causes the behavior to be 
different:

   C:\>klist -c foobar 2>&1 1>klist.out
   klist: No credentials cache found (ticket cache API:foobar)

The error output still doesn't go to the file, but it does go to the 
terminal instead of a Windows dialog.

The reason this happens (and I'm going by the way UNIX redirection works), 
is because "2>&1" says to redirect stderr to the same place as stdout, BUT 
this happens when stdout is associated with the terminal, NOT the file. 
The next part "1>klist.out" says to redirect stdout to a file... but 
stderr is still re-directed to what stdout was BEFORE it was re-directed to 
a file.

The correct (again at least in UNIX) way to redirect both stderr and 
stdout to the same file is this:

   command 1>somefile 2>&1

First you redirect stdout to a file and then you redirect stderr to the 
same place stdout is going... which is now a file.

You can test this concept using any normal dos command that can generate 
both stdout and stderr, eg:

   (you type) C:\>ver 2>&1 1>test.txt
   (you type) C:\>type test.txt
   (displays) Microsoft Windows XP [Version 5.1.2600]

   (you type) C:\>ver /z 2>&1 1>test.txt
   (displays) The syntax of the command is incorrect.
   (NOTE: test.txt is empty)

   (you type) C:\>ver 1>test.out 2>&1
   (you type) C:\>type test.txt
   (displays) Microsoft Windows XP [Version 5.1.2600]

   (you type) C:\>ver /z 1>test.out 2>&1
   (you type) C:\>type test.txt
   (displays) The syntax of the command is incorrect.