[erlang-questions] Issues with stdin on ports

[Richard A. O'Keefe]

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_
programming language.

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.