strange behavior on port send

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

strange behavior on port send

Garry Hodgson-3

i'm trying to interface to an external application, and having
some problems.  i'm using code derived from the "Section 4. Ports"
example in the interoperability tutorial.  the external application
is a colleague's, and i wanted to use the port mechanism to make
it easy for her to interface.

if i build the external program in python, and have it read
its input using the standard python readlines() call, the programs
work just fine.  to make this work, i use the (default) stream and
use_stdio options in the open_port() call.

so now, i'm trying instead to connect it to another
program, written in c.  if i run the program by
hand, and type commands at it, it works just fine.
if i have the erlang open_port() spawn it, when i
send a message i get:

=ERROR REPORT==== 19-May-2001::01:38:50 ===
Bad value on output port '/usr/local/wnet/srv/bravosrv -e
/usr/local/wnet/srv/sample.wnet'

i've tried all variations i can think of to fix this.
i use an explicit read() call, rather than stdin, though
i get the same behavior if i use gets().  i've change it
to use the {packet, 2} option on the erlang side instead,
with the read_cmd() call from the tutorial's sample code.
same thing.

when i first started this stuff, i compiled and ran the
tutorial's example code, and it worked fine.  so i know
there's nothing inherent in talking to c that is a problem.
the program i'm trying to talk to does nothing nasty that i
can see, but it calls some functions to initialize a large
backend set of libraries, written in a mix of c and tcl,
and i'm wondering if maybe there's some ugliness being done
to the file descriptors behind our backs.

does anyone have any ideas?

thanks

--
Garry Hodgson                   sometimes we ride on your horses
Senior Hacker                   sometimes we walk alone
Software Innovation Services    sometimes the songs that we hear
AT&T Labs                       are just songs of our own
garry