S
simon22
Guest
I need to be able to temporarily redirect stdout to a file, and later set it back to what it had been. This is in an MFC, Visual C++ 2017 application. It all happens on one thread in one process. No child processes are involved. I don't want to open a console window or anything like that. The redirection may need to happen any number of times in a given session.
I have found various ways that people say you should be able to do this, but none of them work for me. Here are 3 variations that I have already tried:
Version 1
=========
_wfreopen(sTempFile, L"w", stdout);
....
_wfreopen("CON", L"w", stdout);
Get no output to sTempFile in debug build. In release build, the initial redirect does work, but if anything attempts to send output to stdout after the second call to _wrfeopen (which can happen) it causes the application to crash. Incidentally I tried "CONOUT$" instead of "CON". That also didn't work (is that a console application only thing?).
Version 2
=========
int fd = _dup(1);
FILE *pStream = NULL;
_wfopen_s(&pStream, (sTempFile, L"w");
_dup2(_fileno(*pStream ), 1); // redirect stdout to pStream (1 == "stdout")
....
fclose(pStream);
_dup2(fd , 1); // restore stdout
This version was based on an example on this page: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/dup-dup2?view=vs-2017 . It doesn't cause any crashes but doesn't seem to do anything at all in either debug or release build. Nothing gets output to the temporary file.
Version 3
=========
int fd = _dup(1);
FILE *pStream = _wfreopen(sTempFile, L"w", stdout);
....
fclose(pStream);
_dup2(fd , 1); // restore stdout
Combination of the two approaches, but with same result as version 1. Get no output to sTempFile in debug build. In release build, the initial redirect does work, but if anything attempts to send output to stdout after the call to _dup2 (which can happen) it causes the application to crash.
I have tried other variations but none of them work. I haven't tried using console API functions like GetStdHandle and SetStdHandle because these appear to be designed for use in a console application, and as I say, mine is not a console application and I don't want to open a console window either.
Any help much appreciated.
Simon
Continue reading...
I have found various ways that people say you should be able to do this, but none of them work for me. Here are 3 variations that I have already tried:
Version 1
=========
_wfreopen(sTempFile, L"w", stdout);
....
_wfreopen("CON", L"w", stdout);
Get no output to sTempFile in debug build. In release build, the initial redirect does work, but if anything attempts to send output to stdout after the second call to _wrfeopen (which can happen) it causes the application to crash. Incidentally I tried "CONOUT$" instead of "CON". That also didn't work (is that a console application only thing?).
Version 2
=========
int fd = _dup(1);
FILE *pStream = NULL;
_wfopen_s(&pStream, (sTempFile, L"w");
_dup2(_fileno(*pStream ), 1); // redirect stdout to pStream (1 == "stdout")
....
fclose(pStream);
_dup2(fd , 1); // restore stdout
This version was based on an example on this page: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/dup-dup2?view=vs-2017 . It doesn't cause any crashes but doesn't seem to do anything at all in either debug or release build. Nothing gets output to the temporary file.
Version 3
=========
int fd = _dup(1);
FILE *pStream = _wfreopen(sTempFile, L"w", stdout);
....
fclose(pStream);
_dup2(fd , 1); // restore stdout
Combination of the two approaches, but with same result as version 1. Get no output to sTempFile in debug build. In release build, the initial redirect does work, but if anything attempts to send output to stdout after the call to _dup2 (which can happen) it causes the application to crash.
I have tried other variations but none of them work. I haven't tried using console API functions like GetStdHandle and SetStdHandle because these appear to be designed for use in a console application, and as I say, mine is not a console application and I don't want to open a console window either.
Any help much appreciated.
Simon
Continue reading...