[erlang-questions] Issues with stdin on ports

[Richard A. O'Keefe]

On 30/07/2013, at 2:13 AM, Per Hedeland wrote:
> 
> FWIW, I definitely agree that this is a missing piece of functionality.

Oh it's present in several languages.  You could argue that it's missing.
But is it missing like a car radio in a car that lacks one,
or is it missing like an ejector seat in a car that lacks one?

>> 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.
> 
> Well, it's basically the definition of the traditional pipeline concept
> of the Unix shells, and pipes are obviously what you need to implement
> it - but that doesn't preclude other uses of pipes. The zsh shell even
> allows you to set up "bidirectional pipes" on the commandline.

There are reasons why I don't use zsh.  That's one of them.
> 
>> popen(<command>, "r") reads the output of
>> the command and popen(<command>, "w") writes to the input of the command.
> 
> popen() is effectively a convenience function to abstract away the
> somewhat non-trivial application of pipe(), fork(), close(), and
> execve() that is required to set things up correctly for two particular
> and common usages of pipes in application code. (It is not used by
> common shells to implement pipelines though.)

Having implemented popen() for two other high level languages, I know that.
The fact that common shells do not use it is irrelevant.
> 
>> 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.
> 
> There is no need to have a term for it, since all you need is two pipes,
> one for each direction

Non-sequitur.  If it's a thing you need to do often, it's a thing you
need to be able to talk about.  When I've thought of doing it, I've
used the word David Bacon used in his SETL2 system, "pump".  And then
I've used the phrase "looming disaster" and done something else.

> - and it's probably uncommon enough to not
> warrant its own convenience function. And you can indeed easily deadlock
> if you don't think about what you're doing, but I really doubt that this
> is the reason for any absence of terminology or functions.

It's not that you can easily deadlock,
it's that it's hard *NOT* to deadlock.

>  (the risk is of course reduced due to the fact that the
> VM does non-blocking I/O).

And *that* is the thing that saves Erlang.  Of course, avoiding the
coding complexity of dealing with nonblocking I/O is one of the reasons
for using a multithreading language like Erlang.
>> 
>> Just like it prevents C users from doing the same thing.
> 
> No, there is nothing that prevents C users from doing the same thing.

You may have misunderstood me.
>>>> THE POPEN INTERFACE <<<< prevents C users doing this.
Yes, all the other functions are there, and yes, if you desperately
want to program it, you can.  But it is enough work that nobody
ever does this lightly.

For that matter, it's not beyond the abilities of, say, the glibc
authors, to extend their implementation of popen to support "r+"
or "w+" modes, if there were much demand for it.  (Oddly enough,
Mac OS X 10.7.5 _does_ support "r+" mode, but the Linux I checked
does not.  Weird.)  I have _never_ been able to understand the
differences between Mac OS X and POSIX.