in reply to STDOUT and SWIG

None of what you tried will work for C code. You need to dup() the socket onto file descriptor 1 (which is C's stdout) via:

open(STDOUT,">&$fd") or die ...
you were close in one case but the "=" in your code causes STDOUT to be fdopen()ed to the existing file descriptor so that the socket does not get dup()ed.

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re: (tye)Re: STDOUT and SWIG
by rapier1 (Novice) on Aug 21, 2001 at 00:57 UTC
    tye,

    That was a problem on my part and I am now capturing some small percentage of the data. I'm not sure why I'm not getting all of it unless its overloading the buffers (I've increased sendspace and recvspace to 128k via sysctl - but that still might not be enough - either way I'm still losing the same amount of data).

    What bothers be is that I would think that capturing STDOUT via IO:Scalar should work and I wish I could figure out why its not.

    The partial failure of one method and the complete failure of the other is really annoying me.

      IO::Scalar works by telling Perl that its STDOUT is not an ordinary file handle and so it has to do special processing when Perl's output functions like print try to write to it. C knows nothing of Perl's STDOUT and doesn't use Perl's output functions like print, so IO::Scalar has absolutely no affect on C code (nor on output written by child processes, etc.).

      The order of the layers goes something like this: print, STDOUT, Perl's informal I/O abstraction layer, C's stdio (FILE handles), operating system I/O functions (file descriptors). The C code of SWIG is probably starting at the "C's stdio" layer but could also just be going to the Unix I/O layer of write() and file descriptors. In any case, the C code is not going to be affected by any of the layers above that.

      That is, unless it went out of its way to try to use Perl's I/O routines. I doubt doing that would be easy.

              - tye (but my friends call me "Tye")