[erlang-questions] Output from programs started with open_port

[黃耀賢 (Yau-Hsien Huang)]

I'm more familiar with {line, N} than {packet, 1}. And I think that it's no
matter whether it's {packet, 1} or not. The problem you mentioned is that
when executing C programs it need redirect the error channel to the normal
standard output channel. However, for Erlang port, there is only one channel
called "port," and normal messages and error messages are separated by using
some customized structure within data. Erlang client must known how to
separate different messages in the data. Besides, if an external C process
is linked by the Erlang process, some errors will be propagated to the
Erlang process. Thus instructions for writing them into the error channel,
stderr, can be omitted.


2010/2/3 Samuel Rivas <samuel.rivas@REDACTED>

> Hi,
>
> I have no idea about how to make it work for windows. For linux we had
> the carriage return problem also, but we just went practical and
> redirected the error outuput to a file and used tail -f in other
> terminal. Note that if you can't control the binaries you execute
> there is a chance that they output to stdio as well, confusing your
> port communication (I see you are using {packet, 1} which means that
> the process must write to stdio using a fixed protocol).
>
>
>
> 2010/2/2 黃耀賢 (Yau-Hsien Huang) <g9414002.pccu.edu.tw@REDACTED>:
> > Hi, Ulf.
> >
> > The first message sent out from the C program is fed in stderr and would
> not
> > be caught by the Erlang program. In unixy system the "hello world ..."
> > string is printed when the Erlang process call and execute the C program,
> > while the later one puts those messages in stderr as representing an
> error
> > message. And in Windows those error messages are not showed when the C
> > program puts them into stderr.
> >
> > I think that the Erlang implementation in Windows does not open as port
> as
> > direct executing it. To execute you codes in Windows, I've modified them
> > with another open_port statement:
> >
> > Port = open_port({spawn, "main.exe"}, [{packet,1}]),
> >
> > instead of the original one,
> >
> > Port = open_port({spawn_executable, "./main"}, [{packet, 1}]),
> >
> > and I think that it is different between open_port with spawn and one
> with
> > spawn_executable. Do you agree with me?
> >
> >
> > On Tue, Feb 2, 2010 at 7:04 PM, Ulf Norell <ulfn@REDACTED> wrote:
> >
> >> I'm using open_port to communicate with external programs, and I'm
> having
> >> some problems with the output from these programs. The output I'm
> >> interested
> >> in is mainly debug output so I'd prefer to have it echoed to the
> terminal.
> >> The problem is that on unixy systems (Linux/Mac) newlines are treated
> just
> >> as line feeds without carriage return and on Windows I'm not getting any
> >> output at all.
> >>
> >> Here's a simple example:
> >>
> >> % The Erlang code
> >> -module(simple).
> >>
> >> -compile(export_all).
> >>
> >> test() ->
> >>  Port = open_port({spawn_executable, "./main"}, [{packet, 1}]),
> >>  receive
> >>    {Port, {data, [0]}} ->
> >>      port_close(Port)
> >>  end.
> >>
> >> // The external program
> >> #include <stdio.h>
> >>
> >> int main (void)
> >> {
> >>  fprintf(stderr, "hello\nworld\nHELLO\n\rWORLD\n\r");
> >>  write(1, "\1\0", 2);
> >>  return 0;
> >> }
> >>
> >> On unixy system I get
> >>
> >> 1> simple:test().
> >> hello
> >>     world
> >>          HELLO
> >> WORLD
> >> true
> >>
> >> and on Windows simply
> >>
> >> 1> simple:test().
> >> true
> >>
> >> Having to add \r's when you have the source of the external program is a
> >> nuisance but not the end of the world, but in many cases I don't have
> the
> >> source code of the external program and in that case the output is
> pretty
> >> much useless without proper newlines. On Windows it even worse since I
> >> don't
> >> get any output at all.
> >>
> >> Is this a known issue, and is there anything I can do about it?
> >>
> >> / Ulf
> >>
> >
>
>
>
> --
> Samuel
>