[erlang-questions] Issues with stdin on ports
Richard A. O'Keefe
Mon Jul 29 09:15:52 CEST 2013
On 29/07/2013, at 4:14 PM, Anthony Grimes wrote:
> and communicating with external processes in Erlang. They seem to have
> at least one particular fatal flaw which prevents them from being very
> useful to me, and that is that there is no way to close stdin (and send
> EOF) and then also read from the process's stdout. For example, I cannot
> use a port to start the 'cat' program which listens on stdin for data
> and waits for EOF and then echos that data back to you. I can do the
> first part, which is send it data on stdin, but the only way for me to
> close it is to call port_close and close the entire process.
Note that "only send data to a command" and "only receive data from a
command" are the traditional ways for a UNIX program to communicate
with another over a pipe. popen(<command>, "r") reads the output of
the command and popen(<command>, "w") writes to the input of the command.
There isn't even any standard _term_ for talking about connecting to both
stdin and stdout of a command in UNIX, and that's because it's an
incredibly easy way to deadlock.
> This issue prevents Erlang users from doing any even slightly more than
> trivial communication with external processes without having some kind
> of middleman program that handles the creation of the actual process you
> need to talk to and looks for a specific byte sequence to indicate 'EOF'.
Just like it prevents C users from doing the same thing.
Unless they fake something up using named pipes or UNIX-domain sockets.
(Or message queues. I do wish Mac OS X implemented rather more of POSIX...)
Unix anonymous pipes are simply the wrong tool for the job in _any_
The historic way to do "slightly more than trivial communication with
external processes" has been to set the external processes up as C nodes
or to use sockets.
More information about the erlang-questions