Redirecting stdout/err under win32 platform

[David Douard]

Hi everybody,

let me explain by problem:
I am working on an application which consists in a C++ dll (numeric
computations) and a Python IHM (Python/Tk), which must run under Linux and
win32. My problem is the C++ lib does write stuffs on its stdout, and I
would like to print those messages in a Tk frame. When I run the
computation, it has it's own thread.

So my question is : how van I redirect the dll's stdout to something I can
retrieve in Python (pipe, socket,...)?

I can do it easily under Linux. I made tests with a socket which just works
fine. In the threaded function (that will do the heavy computation), I
write:

import os, sys
from socket import *
s=socket(AF_UNIX, SOCK_STREAM)
s.connect(...)
os.dup2(sys.__stdout__.fileno(), s.fileno())
very_intensive_function(many_parameters)
s.close()

That's OK under Linux, but does not work under win32 (even if I use an INET
localhost socket), cause I cannot do the os.dup2 trick (Windows does not
want to consider a socket as a file! What a shity system!).

So my question is : is there a simple solution ? I have tested different
solutions. I am trying hacks with pipes created with the win32api. But I
have not yet managed this simple operation.

Note that I have no access to the dll source code, so I cannot modify it so
it uses a named pipe (for example) as message output pipe instead os
stdout...

Thanks,
David

[yaipa]

David,

Googling comp.lang.python /w this string "stderr win32" yielded 109
results.
So I think if you poke around a bit you will find your answer in the
archives.

Sorry for no direct help tonight...

Cheers,

--Alan
David Douard wrote:

Hi everybody,

let me explain by problem:
I am working on an application which consists in a C++ dll (numeric
computations) and a Python IHM (Python/Tk), which must run under Linux and win32. My problem is the C++ lib does write stuffs on its stdout, and I would like to print those messages in a Tk frame. When I run the
computation, it has it's own thread.

So my question is : how van I redirect the dll's stdout to something I can retrieve in Python (pipe, socket,...)?

I can do it easily under Linux. I made tests with a socket which just works fine. In the threaded function (that will do the heavy computation), I write:

import os, sys
from socket import *
s=socket(AF_UNIX, SOCK_STREAM)
s.connect(...)
os.dup2(sys.__stdout__.fileno(), s.fileno())
very_intensive_function(many_parameters)
s.close()

That's OK under Linux, but does not work under win32 (even if I use an INET localhost socket), cause I cannot do the os.dup2 trick (Windows does not want to consider a socket as a file! What a shity system!).

So my question is : is there a simple solution ? I have tested different solutions. I am trying hacks with pipes created with the win32api. But I have not yet managed this simple operation.

Note that I have no access to the dll source code, so I cannot modify it so it uses a named pipe (for example) as message output pipe instead os
stdout...

Thanks,
David

[David Douard]

Alan,

I did search Google for this problem (not enough, thou).
In fact, I found some kind of solution (by myself, not that much on Google),
but it is not really satisfactory.

I have used win32 pipes to do so (win32api.CreatePipe). I can redirect
stdout/stderr to it from my python code (even redirecting the stdout/stderr
from my C lib).
But I still have a problem with this solution (well, 2):
- it is *much* more complicated than any solution available on Unix like
systems (not really a problem, but),
- it not synchronous at all. And I'd like it to be so (or almost so).

David

yaipa wrote:

David,

Googling comp.lang.python /w this string "stderr win32" yielded 109
results.
So I think if you poke around a bit you will find your answer in the
archives.

Sorry for no direct help tonight...

Cheers,

--Alan
David Douard wrote:

Hi everybody,

let me explain by problem:
I am working on an application which consists in a C++ dll (numeric
computations) and a Python IHM (Python/Tk), which must run under

Linux and

win32. My problem is the C++ lib does write stuffs on its stdout, and

I

would like to print those messages in a Tk frame. When I run the
computation, it has it's own thread.

So my question is : how van I redirect the dll's stdout to something

I can

retrieve in Python (pipe, socket,...)?

I can do it easily under Linux. I made tests with a socket which just

works

fine. In the threaded function (that will do the heavy computation),

I

write:

import os, sys
from socket import *
s=socket(AF_UNIX, SOCK_STREAM)
s.connect(...)
os.dup2(sys.__stdout__.fileno(), s.fileno())
very_intensive_function(many_parameters)
s.close()

That's OK under Linux, but does not work under win32 (even if I use

an INET

localhost socket), cause I cannot do the os.dup2 trick (Windows does

not

want to consider a socket as a file! What a shity system!).

So my question is : is there a simple solution ? I have tested

different

solutions. I am trying hacks with pipes created with the win32api.

But I

have not yet managed this simple operation.

Note that I have no access to the dll source code, so I cannot modify

it so

it uses a named pipe (for example) as message output pipe instead os
stdout...

Thanks,
David

[Pierre Barbier de Reuille]

David Douard a écrit :

Alan,

I did search Google for this problem (not enough, thou).
In fact, I found some kind of solution (by myself, not that much on Google),
but it is not really satisfactory.

I have used win32 pipes to do so (win32api.CreatePipe). I can redirect
stdout/stderr to it from my python code (even redirecting the stdout/stderr
from my C lib).
But I still have a problem with this solution (well, 2):
- it is *much* more complicated than any solution available on Unix like
systems (not really a problem, but),
- it not synchronous at all. And I'd like it to be so (or almost so).

David

AFAIK, there is no working bidirectionnal pipes on Windows ! The
functions exists in order for them to claim being POSIX, but they're not
working properly. Under Windows environment, I suppose you have to find
your way using their buggy pipes (and by no means their "POSIX" pipes)
or you have to use another inter-process communication protocol (DDE,
COM, ...).

Pierre