Is there a way to undo Rhino's suppression of all command line output

Rhino Developer
1

Hi everyone!
When developing a plugin (in whatever language) it sometimes happens that one uses a library which outputs diagnostic messages on the output … for instance, there might be a C++ library that contains lines such as fprintf(stdout, “Hello from me”) or some std::cout << “hello” << std::endl etc.
It seems Rhino suppresses all these messages. Starting Rhino from the command line runs Rhino but results in silence so Rhino forbids their mouth very decisively.
Is there a way to re-enable the command line output?
I can’t easily re-direct these debug messages to a file because they happen inside some large third-party code that I can’t unearth so easily.
This is a big impediment to a good debugging experience.
Thanks!

2

In case anyone wonders about the same: I found a makeshift solution: to steal stdout and stderr before Rhino can mute it, using https://en.cppreference.com/w/c/io/freopen . This intercepts all stdout and stderr output that would usually end on the console. Not sure if it prevents all console output from being silenced, though.
Also, why does Rhino behave that way?

3

Hi @mathias.fuchs,

The quick answer is that, like most GUI applications, Rhino does not have a console window. Thus, operations like std::cout will not print to Rhino’s command window.

That said, you can use the OutputDebugString function or the TRACE macro (MFC), which lets you do printf -style formatting, to Visual Studio’s output window.

int x = 1;
int y = 16;
float z = 32.0;
TRACE( "This is a TRACE statement\n" );    
TRACE( "The value of x is %d\n", x );
TRACE( "x = %d and y = %d\n", x, y );
TRACE( "x = %d and y = %x and z = %f\n", x, y, z );

– Dale

4

Thank you for the answer but I think there is a misunderstanding here. I am aware that Rhino does not have a console window, and I am not expecting std::cout to go to Rhino’s command prompt.
Instead, I would have expected that when I start Rhino from Windows’ command prompt, it does allow the stdout from third-party libraries to go through to the command prompt. This is the default behavior for most applications, whether they expose a GUI in their own window or not.
Also, as I said I am using third-party libraries whose source code can’t be altered easily, or which might just come as a shared library. In that case, I can’t use the OutputDebugString function. There is no way around redirecting stdout somewhere else before issuing calls into that library.

5

Hi @mathias.fuchs,

Do you have an example of an application that works this way?

Thanks,

– Dale

6

not yet, but I keep looking :slight_smile: I might have confused it with Linux’ behavior …