Thx,
Skip
stderr is not knowingly captured by nose (AFAIK). what were you doing
that captured stderr? Maybe it's a rogue plugin or something in your
app that captured stderr but did not release it.
K
I have a C library wrapped w/ Boost.Python which emits some error messages
to stderr using fprintf(stder, ...). When I run the test under nose I
don't see the
error message, but when I run from a Python interpreter I do.
S
what happens in the same test if you do:
print >>sys.stderr, "printed to stderr"
if you can't see that, then try:
print >>sys.__stderr__, "printed to actual stderr"
if you can't see that, then something really strange is going on. If
you can't see the first print but *can* see the second print, then
something has hijacked sys.stderr and you'd have to debug the code to
try and figure out where the hijacking occurred.
Both work as expected. It appears that only my C-level stderr prints
are being swallowed.
Skip
No idea then. File a bug at Boost.Python ? :) Sounds like
fprintf(stder,...) is going to Python's stdout, right?
Kumar> No idea then. File a bug at Boost.Python ? :) Sounds like
Kumar> fprintf(stder,...) is going to Python's stdout, right?
I don't see how it could be a Boost.Python problem. It displays fine when I
execute the code from the Python prompt. I wound up just taking the prints
out anyway, so I'm not going to spend anymore time on the problem. Got
bigger fish to fry.
Skip
right, which leads me to believe that the compiled Boost.Python code
is sending the msg to stdout. That would be easy enough to verify.
If this is true, then that would be a bug in Boost.Python since
fprintf(stder, ...) is not handled correctly.