Redirect stderr/stdout to a file using SetStdHandle

[daniel]

Hi all,

I have the following code snippet, that tries to redirect a program's
standard output/error to a file.

HANDLE fHandle;

fHandle = CreateFile(...);

SetStdHandle(STD_OUTPUT_HANDLE, fHandle);
SetStdHandle(STD_ERROR_HANDLE, fHandle);

fprintf(stdout, "string #1\n");
fprintf(stderr, "string #2\n");

...but it doesn't work. Output text goes to console instead of file.

Any ideas?

[je...@automationservicesco.com]

Try freopen () and/or fdopen ()

[daniel]

Your idea seems to be fine but I want to understand why it doesn't
work in this situation.
thanks,
Daniel.

[Jonathan de Boyne Pollard]

I have the following code snippet, that tries to redirect a program's standard output/error to a file.

HANDLE fHandle = CreateFile(...);

SetStdHandle(STD_OUTPUT_HANDLE, fHandle);
SetStdHandle(STD_ERROR_HANDLE, fHandle);

fprintf(stdout, "string #1\n");
fprintf(stderr, "string #2\n");

...but it doesn't work. Output text goes to console instead of file.  Any ideas?

By the time that your code comes to execute, your runtime library has already queried Win32 for the standard handle numbers, and saved them in internal library data structures.  Whatever subsequent alterations you make at the Win32 level, the stdout and stderr streams end up using the Win32 handle numbers that were already saved.  You need to alter the runtime library's idea of what those Win32 handles are.  Of course, the mechanism for doing this is highly specific to which C/C++ implementation you are using. 

For OpenWatcom, for example, this involves the creative use of the close() and _open_osfhandle() functions to re-map (library) file descriptors 0, 1, and 2 to different underlying Win32 handles (obtained from CreateFile() of course).  This will make the file-descriptor-level I/O functions such as read() and write() use the new Win32 handles.  One then needs to ensure that stdin, stdout, and stderr are open and associated with file descriptors 0, 1, and 2, if this is not already the case.

[Michael Wojcik]

daniel wrote:
> On Mar 4, 6:08 am, j...@automationservicesco.com wrote:
>> On Mar 3, 3:10 pm, daniel <daniel.bal...@gmail.com> wrote:
>>> I have the following code snippet, that tries to redirect a program's
>>> standard output/error to a file.
>>> HANDLE fHandle;
>>> fHandle = CreateFile(...);
>>> SetStdHandle(STD_OUTPUT_HANDLE, fHandle);
>>> SetStdHandle(STD_ERROR_HANDLE, fHandle);
>>> fprintf(stdout, "string #1\n");
>>> fprintf(stderr, "string #2\n");
>>> ...but it doesn't work. Output text goes to console instead of file.

>> Try freopen () and/or fdopen ()
>
> Your idea seems to be fine but I want to understand why it doesn't
> work in this situation.

stdout and stderr are not file handles. They're FILE* objects.[1]

When main is invoked, stdin, stdout, and stderr will have been created
for you by the environment[2] (modulo freestanding versus hosted
implementation, etc). They'll be created from the standard input,
output, and error handles, respectively.

But changing those handles after stdin, stdout, and stderr have been
created will make no difference to stdin et al. They've already been
created.

Changing STD_OUTPUT_HANDLE will affect subsequent writes *to that
handle*, and it'll be inherited by subsequent child processes (if you
don't override the child's standard handles in CreateProcess).

To change the FILE* objects that stdin, stdout, and stderr refer to,
you need to use freopen. That's the only mechanism endorsed by the C
standard.

Now, since some functions will write to the standard I/O FILE objects,
and some to the standard I/O handles, it's best to reassign both,
unless you know all the output you want redirected will be using one
abstraction or the other.

[1] "objects" in the C sense, not the C++ sense. (Of course in a
conforming C++ implementation, FILE will be a struct type, so stdout
and stderr will be pointers to C++ objects of FILE type.)

[2] "environment" as used in the C standard, not in the sense of a
collection of name=value string pairs accessible through getenv, etc.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[m]

Another possibility is to use the /ENTRY linker option to change the entry point to a routine that sets these values and then calls WinMainCRTStartup.  This is also CRT and linker specific, but at least this way you sit under the CRT and there is no chance that the first few IOPs will be lost.

"Jonathan de Boyne Pollard" <J.deBoynePoll...@NTLWorld.COM> wrote in message news:IU.D20100304.T...@J.de.Boyne.Pollard.localhost...

[Jonathan de Boyne Pollard]

Now, since some functions will write to the standard I/O FILE objects, and some to the standard I/O handles, it's best to reassign both, unless you know all the output you want redirected will be using one abstraction or the other.

Actually, there are three APIs, not two.  I'm surprised to find that although answers to this are frequently given, they're frequently wrong, too, including one such answer that was published in Windows Developer Journal.  Hence I've written a Frequently Given Answer on redirecting standard I/O from within a program.

[Michael Wojcik]

Jonathan de Boyne Pollard wrote:
>
>> [I wrote:]

>> Now, since some functions will write to the standard I/O |FILE|
>> objects, and some to the standard I/O handles, it's best to reassign
>> both, unless you know all the output you want redirected will be using
>> one abstraction or the other.
>>
> Actually, there are three APIs, not two.

Quite right, and I ought to have mentioned that. Thanks for the
correction. (The third, for anyone who hasn't read the document
Jonathan posted the link to, is the POSIX API.)

I tend to avoid mixing the POSIX and Win32 APIs in the same program,
where possible, so I didn't think of mentioning the POSIX I/O
functions in my previous post. But even if the programmer writing the
main program avoids the POSIX functions, it's entirely possible
library code will call them.